Release Methodology

[dalben]

More common terms these days are EOL and EOS.

 

End Of Life.  A product is superseded and it is no longer sold or enhanced by the vendor.

End Of Support is when the vendor ceases to support and supply bug and security fixes.

 

In this case, 6.1.9 would go EOL when 6.2 goes live.  But it sounds like LT want EOL and EOS to happen at the same time. I can understand why but it's not normally done.

[BRiT]

So using those terms, did 6.1.9 go EOS 6 months ago when they stopped supplying bug fixes and security updates then?

[dalben]

Um, yeah. Which is a bit odd seeing it's the official stable release.

[garycase]

Um, yeah. Which is a bit odd seeing it's the official stable release.

 

Agree.

 

 

[NAS]

I strongly agree with all of above but at the same time I think if we keep focusing solely on previous mistakes without suggesting specific fixes (preferably in terms of methodology wording changes) then we are doomed to be ignored here and nothing will be fixed.

 

We have made big progress by getting some commitment to change so we should captialise on this and just be more positive to make this a positive toned thread and not a negative one.

 

However feel free to cry havoc if we continute to repeat past mistakes, I plan to but that cant happen until at least 1 month after the first post 6.2 release CVE.

 

To that end I quote my initial comments which we havent addressed yet

 

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.

 

and a further issue

 

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.

 

I want to point out again though that since the conversations were split from the RC thread in an endeavour to clear the air and make progress we have made no appreciable difference to any policy. I am happy to help but this has to be a two way street. I wont continue to waste effort talking to myself in the hope someone answers me one day.

[limetech]

Currently we are not making any progress at all.

We have updated our Policies page with more details regarding Privacy:

https://lime-technology.com/policies/

[limetech]

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).

There is no more 'call home' starting in 6.2.0-rc5 unless you are using a Trial key.  Trial will always require internet access in order to validate.

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

If you want to stay on "stable" releases, you won't have to do anything: the built-in "unRAIDServer.plg" file will trigger updates whenever a new stable release is available.  We will also create a post in the Announcement board for new stable releases.

 

If you want to use the latest and greatest development, you will install the "unRAIDServer-next.plg" file.  This will trigger updates whenever a new development release is available.  We will typically not post announcements for these releases.

 

We will provide more details upon release of 6.2 stable.

 

[NAS]

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).

There is no more 'call home' starting in 6.2.0-rc5 unless you are using a Trial key.  Trial will always require internet access in order to validate.

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

If you want to stay on "stable" releases, you won't have to do anything: the built-in "unRAIDServer.plg" file will trigger updates whenever a new stable release is available.  We will also create a post in the Announcement board for new stable releases.

 

If you want to use the latest and greatest development, you will install the "unRAIDServer-next.plg" file.  This will trigger updates whenever a new development release is available.  We will typically not post announcements for these releases.

 

We will provide more details upon release of 6.2 stable.

 

I would have preferred that we iron out the final wording before 6.2 but I accept that not everything can be the top of the todo list. Lets put  a pin in this until 6.2 is released but at that point it has to becomes a priority and certainly needs completed before 6.2.1.

[NAS]

Now that 6.2 is out we need to complete this methodology ASAP. especially in light of the fact 6.2 already is missing one CVE (Curl CVE-2016-7167).

 

Crazy as it sounds the 6.2.1 release clock is already T plus 2 days

[ken-ji]

And I'll reiterate that we should have a early package/patching system for emergencies or situations like this.

 

I understand and appreciate the appeal of an ramdisk based OS (very easy to fix any problems), but we really ought to be flexible too and allow broken/breaking stuff to be patched. and the easiest is a directory for packages of stuff from Slackware or LT to be applied early in the boot process.

[Toggle]

I think it's clear, concise and on thorough.

[bmartino1]

http://www.slackware.com/security/

Posting for convince to Slackware current list

Slackware Linux Security Advisories