Release Methodology


limetech

Recommended Posts

At present we are maintaining two code branches:  latest stable and development.

 

The latest stable is always the first entry listed under Stable Releases on the website Download page.  The development releases are only publicized in the forum Announcement board.

 

If a relevant Slackware Security Advisory package update becomes available (or other kind of security update), we update both the latest stable and development branches.  For the latest stable branch, we then increment the patch level of the release version (the third digit) and publish the new release as soon as practical.  Other critical bug fixes may also trigger publishing another latest stable patch release.

 

Of the stable releases listed on the Download page, only the latest stable will be updated.  That is, we do not maintain multiple old stable releases at this time.  Updates are free and users are encouraged to keep up-to-date.

 

For the development branch, an updated release may or may not be published at the same time as the new stable release, but any package updates or bug fixes which go into latest stable are first integrated into development and tested.

 

Anyone who discovers a security-related issue is encouraged to post here so that we can integrate necessary patches in a timely manner.

Link to comment
  • 11 months later...

I want to apologize for doing a piss poor job of keeping 6.1.x "latest stable" up to date with regards to CVE's.  We were doing ok until sometime after March 4, 2016 when 6.1.9 was released.  We fully expected 6.2 to be released soon thereafter.  But one thing led to another, and 6.2 has been drug out much longer and in the interim we quit updating the 6.1.x branch because, well, "we are always very close to releasing 6.2".

 

This will be in the 6.2-rc5 announcement post as well, but here is our plan.  We will release 6.2.0-rc5 and barring a show-stopper, that will be the last -rc, and then we will release 6.2 'stable' with nothing more significant than a version number change.  There will be some "known issues" in 6.2 which will be addressed in 6.2.1, but as of now, it will not be productive for us to generate a 6.1.10 and then within days release 6.2.

 

I hope everyone understands, and we as a team really do take security seriously, though I can see it might not look that way.  We are committed to getting more proactive in this area, but as they say, talk is cheap.  I know there are several long time unRAID users who will hold our feet to the fire.

 

 

Link to comment

At present we are maintaining two code branches:  latest stable and development.

 

The latest stable is always the first entry listed under Stable Releases on the website Download page.  The development releases are only publicized in the forum Announcement board.

 

If a relevant Slackware Security Advisory package update becomes available (or other kind of security update), we update both the latest stable and development branches.  For the latest stable branch, we then increment the patch level of the release version (the third digit) and publish the new release as soon as practical.  Other critical bug fixes may also trigger publishing another latest stable patch release.

 

Of the stable releases listed on the Download page, only the latest stable will be updated.  That is, we do not maintain multiple old stable releases at this time.  Updates are free and users are encouraged to keep up-to-date.

 

For the development branch, an updated release may or may not be published at the same time as the new stable release, but any package updates or bug fixes which go into latest stable are first integrated into development and tested.

 

Anyone who discovers a security-related issue is encouraged to post here so that we can integrate necessary patches in a timely manner.

 

Clear, concise and on thorough.

 

Few suggestions:

 

1. You likely plan to do this anyway but once you are happy, these words need promoted to the website and away from the forum

2. You need a private means of reporting security issues so that you have a reasonable chance of closing the 0-day before it is made public. Otherwise the risk of user breaches is much greater and the pressure on you to fix faster is unnecessarily high.

 

I drafted an example for you... wording similar to this would probably cover it:

 

If you discover a security issue in an Limetech LLC product or service, we ask that you report it to us confidentially in order to protect the security of our users and services. Please email the details to [email protected]. On receipt we will respond directly to acknowledge your report and if necessary open a dialogue to better understand the details. From here we will plan the mitigation and set a timeline for a new release or patch. As is ethical we will credit the security report to the individual/group/researcher within any news items and also the release notes.

 

3. You are mixing security policy words and release methodology although given how clear and related they are I like where it is going.

 

4. You need a means to inform users. Currently unless you have notifications set there is a large chance you will not see a new release. Also there is no urgency levels on these notifications and also as we have seen many users have unRAID specifically setup with no internet. You dont need to force users into any type of scheme but one should exist.

 

5. It is not clear yet how and when packages are updated i.e. https://lime-technology.com/forum/index.php?topic=51308.msg494236#msg494236 I have no strong preference here as all options have pros and cons, we just need to decide on one so users know what to expect.

 

 

On a general note though I have to say that whilst the 6.1 line was being patched both the time line and the release notes were very good. I dont see any need to do more than this and this push to tie up and formalise the process get a huge thumbs up from me.

 

Link to comment

I want to apologize for doing a piss poor job of keeping 6.1.x "latest stable" up to date with regards to CVE's.  We were doing ok until sometime after March 4, 2016 when 6.1.9 was released.  We fully expected 6.2 to be released soon thereafter.  But one thing led to another, and 6.2 has been drug out much longer and in the interim we quit updating the 6.1.x branch because, well, "we are always very close to releasing 6.2".

 

This will be in the 6.2-rc5 announcement post as well, but here is our plan.  We will release 6.2.0-rc5 and barring a show-stopper, that will be the last -rc, and then we will release 6.2 'stable' with nothing more significant than a version number change.  There will be some "known issues" in 6.2 which will be addressed in 6.2.1, but as of now, it will not be productive for us to generate a 6.1.10 and then within days release 6.2.

 

I hope everyone understands, and we as a team really do take security seriously, though I can see it might not look that way.  We are committed to getting more proactive in this area, but as they say, talk is cheap.  I know there are several long time unRAID users who will hold our feet to the fire.

 

To play Devil's Advocate, I'd like to give a reason for creating 6.1.10:

6.2 runs a new version of the kernel and some of the stock OS commands returns data in a different format than the same command in 6.1.x. Programs that expect data to exist in a certain spot from these modified commands are now broken under 6.2. My disk speed script in my sig doesn't function under 6.2 for example but does for every version from 5.0 to 6.1.9

 

One advantage to UNRAID is it's versatility. There are many released scripts & plugins available but who knows how many custom scripts are out there that people have written/acquired for their own use that may be broken under 6.2 forcing them to roll back if they're critical to them.

Link to comment

I want to apologize for doing a piss poor job of keeping 6.1.x "latest stable" up to date with regards to CVE's.  We were doing ok until sometime after March 4, 2016 when 6.1.9 was released.  We fully expected 6.2 to be released soon thereafter.  But one thing led to another, and 6.2 has been drug out much longer and in the interim we quit updating the 6.1.x branch because, well, "we are always very close to releasing 6.2".

 

This will be in the 6.2-rc5 announcement post as well, but here is our plan.  We will release 6.2.0-rc5 and barring a show-stopper, that will be the last -rc, and then we will release 6.2 'stable' with nothing more significant than a version number change.  There will be some "known issues" in 6.2 which will be addressed in 6.2.1, but as of now, it will not be productive for us to generate a 6.1.10 and then within days release 6.2.

 

I hope everyone understands, and we as a team really do take security seriously, though I can see it might not look that way.  We are committed to getting more proactive in this area, but as they say, talk is cheap.  I know there are several long time unRAID users who will hold our feet to the fire.

 

To play Devil's Advocate, I'd like to give a reason for creating 6.1.10:

6.2 runs a new version of the kernel and some of the stock OS commands returns data in a different format than the same command in 6.1.x. Programs that expect data to exist in a certain spot from these modified commands are now broken under 6.2. My disk speed script in my sig doesn't function under 6.2 for example but does for every version from 5.0 to 6.1.9

 

One advantage to UNRAID is it's versatility. There are many released scripts & plugins available but who knows how many custom scripts are out there that people have written/acquired for their own use that may be broken under 6.2 forcing them to roll back if they're critical to them.

 

it does not seem logical

you suggest they maintain two parallel versions

6.1.x

and

x being 6.2 in a few days and so on

 

sometime 6.1.x has to stop being developed

 

when it was released sounds fair so all the development goes to the new versions

Link to comment

I want to apologize for doing a piss poor job of keeping 6.1.x "latest stable" up to date with regards to CVE's.  We were doing ok until sometime after March 4, 2016 when 6.1.9 was released.  We fully expected 6.2 to be released soon thereafter.  But one thing led to another, and 6.2 has been drug out much longer and in the interim we quit updating the 6.1.x branch because, well, "we are always very close to releasing 6.2".

 

This will be in the 6.2-rc5 announcement post as well, but here is our plan.  We will release 6.2.0-rc5 and barring a show-stopper, that will be the last -rc, and then we will release 6.2 'stable' with nothing more significant than a version number change.  There will be some "known issues" in 6.2 which will be addressed in 6.2.1, but as of now, it will not be productive for us to generate a 6.1.10 and then within days release 6.2.

 

I hope everyone understands, and we as a team really do take security seriously, though I can see it might not look that way.  We are committed to getting more proactive in this area, but as they say, talk is cheap.  I know there are several long time unRAID users who will hold our feet to the fire.

 

To play Devil's Advocate, I'd like to give a reason for creating 6.1.10:

6.2 runs a new version of the kernel and some of the stock OS commands returns data in a different format than the same command in 6.1.x. Programs that expect data to exist in a certain spot from these modified commands are now broken under 6.2. My disk speed script in my sig doesn't function under 6.2 for example but does for every version from 5.0 to 6.1.9

 

One advantage to UNRAID is it's versatility. There are many released scripts & plugins available but who knows how many custom scripts are out there that people have written/acquired for their own use that may be broken under 6.2 forcing them to roll back if they're critical to them.

 

it does not seem logical

you suggest they maintain two parallel versions

6.1.x

and

x being 6.2 in a few days and so on

 

sometime 6.1.x has to stop being developed

 

when it was released sounds fair so all the development goes to the new versions

 

Security updates are not development. When you only have 1 released product version you need to keep security patches provided for them in a timely manner.

 

In this situation the only supported released product version is 6.1.x. And it absolutely needs to be maintained with proper security fixes.

Link to comment
it does not seem logical

you suggest they maintain two parallel versions

6.1.x

and

x being 6.2 in a few days and so on

 

sometime 6.1.x has to stop being developed

 

when it was released sounds fair so all the development goes to the new versions

 

It's logical to have at least one security patch upgrade on the existing stable release when the next release includes a kernel subversion bump (4.1 to 4.4).

Link to comment

I don't disagree.

But if you read carefully the second post, 6.1.9 was not anymore updated because 6.2 was about to be released.

 

And if you ask for 6.1.10 for plugins/script compatibility, why not release 6.1.11 in a few months.

 

 

Also, (I am asking) security patching never produces bugs?

 

Lastly, as UnRaid is not the safest OS out there and everyone knows about it, using proper firewall rules provides the best "security patch".

It's not the same, but by firewall securing the server, the security holes can not be accessed.

 

 

Link to comment

No one on this forum has been more vocal for updating 6.1.9 with security releases than me but we have to be pragmatic. I see this post as a confirmation of what will happen form 6.2 onwards were we can start with a blank slate and get it right. Its not ideal but its a reality even I can live with.

 

Keep in mind it is highly likely this process will be put to the test with days and certainly not more than a few weeks from the 6.2 release. As far as I am aware there has not been a single month in 2016 that a SSA has not been release that would require a new unRAID.

 

The downside of this is that the current plan means that no one will have an uptime greater than one month ever again.

 

 

 

 

Link to comment

No one on this forum has been more vocal for updating 6.1.9 with security releases than me ...

 

THAT is a significant UNDERSTATEMENT  :)  NAS has absolutely been the loudest voice around on security patches -- both publicly and in the private moderator's forum.

 

My nickel's worth =>  The 6.1.x releases are indeed the "stable" release thread; and, as such, should absolutely have had more security updates.    In addition, many will likely want to simply stay with this release for a couple of reasons:  (a)  If they don't need (or want) dual parity, there's really no compelling reason to switch;  (b) the 6.2 series is notably more CPU-intensive, so if someone's running an older system with a relatively low-power CPU and doesn't need more "horsepower" for VM's or Dockers, they may simply not want to "fix what ain't broken".

 

IMHO, dual parity is enough of a compelling feature to move to 6.2; but many won't feel the need for that extra layer of protection [perhaps because they always maintain good backups; or are simply willing to take the risk of data loss].  This is somewhat analogous to those who stayed on v4.7 for a LONG time after v5 was released (I actually still know a few folks on 4.7) => it was (and indeed still is) a VERY stable platform, and if you didn't need support for drives > 2TB there weren't really many compelling reasons to update if your system was purely a NAS.

 

In any event, I'm definitely in favor or a 6.1.10 release to update the security issues for that series.

 

Link to comment

Then we have no choice but we release 6.2 as soon as possible (warts and all) as the fix the the 6.1 series security holes.

 

I do like where we are going in terms of long term methodology fixes but we cant forget that we are in a terrible position today.

Link to comment

In any event, I'm definitely in favor or a 6.1.10 release to update the security issues for that series.

 

Not going to happen.  Once 6.2 'stable' is released, 6.1 is no longer supported.  We simply don't have the resources to maintain multiple release trees.

 

Understand => but note that "Once 6.2 'stable" is released, 6.1 is no longer supported" IMPLIES that BEFORE 6.2 stable is released, 6.1 IS supported => yet there have been no updates in over 6 months.  NAS has, of course, been VERY vocal in pointing this out as time has passed by and the outstanding security issue list has grown.

 

 

 

Link to comment

I can't understand why you insist so much.

You use an insecure OS so you have to protect it.

You ask for 6.1.10 because you or someone else doesn't like 6.2. If they release 6.1.10 today are you going to ask for 6.1.11 in a month when new security holes will have been discovered?

 

Actually I use v6.2 RC4, but I agree with NAS that there should be security updates for the current "stable release".    And many folks will likely stay with v6.1.x if they don't want or need dual parity.  I simply don't think the "stable release" should be abandoned BEFORE there is a newer stable version.

 

Link to comment

I agree in an ideal world 6.1.10 should happen but we have to realistic and pick the battles we can win, it is simply not viable at this point to ask for a second parallel beta cycle (because a 6 month cumulative security update that includes many core packages and more than one kernel bump is too big a change to release as stable directly) .

 

The time for 6.1.10 was months ago, in fact we should be on about 6.1.16 now.

 

RC5 without the call home within a week is the battle we should fight.

Link to comment

Agree.  Hopefully in the future frequent security updates will be the norm and this situation won't recur.

 

If not, we'll be in the same situation when 6.2 is ignored while 6.3 is being developed; etc.

 

As for RC5 "within a week" => as always, my vote is for ensuring it's right rather than pushing for "quick".  It does, however,  "feel" like the stable release is indeed getting very close  :)

 

Link to comment

Indeed but let me reword.... RC5 could simply be RC4 without the call home. This would IMHO be the current best compromise for those that want the security fixes but dont accept the call home.

 

On that note the release methodology does not contain any call home provision so we need to add that to be clear when it will and wont be used.

Link to comment

Seems sensible. You might as well think about the "call home" wording now because it is going to be asked soon since all definitions so far have been for beta and RC (which no longer exist so the wording becomes invalid).

 

You are also going to be asked how the community will test all their eclectic setups and hardware if there is no beta cycle.

Link to comment

We really need to start making moves on firming up and expanding this Release Methodology and the privacy policy. These IMO should be roadblocks for the 6.2 release and not independent "at some future date" deliverables.

 

Currently we are not making any progress at all.

 

I understand everyone is busy but that is not going to change any time soon and if we dont do it we can expect the same kind of upswell as we seen over the last few weeks in the 6.2 release discussions which will sour what should be a big event.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.