NAS
-
Posts
5040 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by NAS
-
-
As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.
It's not a feature, it's a bug fix.
Again its all in the wording.
No one can possibly be expected to read "- add experimental global share setting: "Tunable (enable Direct IO)"" as a bug fix changelog.
I suggest that even if it is a bug fix that it should have been in the next beta testing and not the last RC. Thats how most people would have done it.
Point taken. But it has been properly illuminated in this topic and I'm not going to generate a -rc6 just to change the wording of a change log entry.
Just for clarity on what I was saying and I really dont expect a reply I was not suggesting RC6 i was saying that the model people expect when you announce an RC is that all the new stuff, as in every single thing would stop and traditionally been pushed to the 6.3 cycle.
Any other ramblings I will post in the right thread. I really dont want to OT this one.
-
As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.
It's not a feature, it's a bug fix.
Again its all in the wording.
No one can possibly be expected to read "- add experimental global share setting: "Tunable (enable Direct IO)"" as a bug fix changelog.
I suggest that even if it is a bug fix that it should have been in the next beta testing and not the last RC. Thats how most people would have done it.
-
As spotted by other users here http://lime-technology.com/forum/index.php?topic=51605.msg495311#msg495311 the actual defitnion of RC for unRAID is non standard and needs defined.
-
- get rid of release validation for -rc releases with Basic/Plus/Pro
Does this mean that the "phone home" 'feature' has been removed and that it will start up in the absence of an Internet connection?
That would be my interpretation as well but the new wording for the feature (release validation ) adds just enough doubt to make me want to confirm this as well.
For Basic/Plus/Pro keys no interaction with any outside server takes place. Trial still requires access to our key server to validate. You could of course test this yourself by unplugging your network cable and reboot your server.
To be fair that only tests that the server boots and not that the system doesn't call home. The two were related previously but they dont have to go hand in hand.
The correction for CVE-2016-5696 actually took place in linux kernel 4.4.18 which we upgraded to in 6.2.0-rc4. The full change log available from the webGui Plugins page or our website Download page reflects that.
oops my mistake sorry. I have not been keeping fully up do date as I used to with unRAID CVEs because I dont run the RC (due to the call home) and I gave up hope on 6.1.9 a few months ago. I will start again post RC5 with renewed vigor.
As for the "experimental" feature in RC5. You got to realize guys do yourself no favours by adopting a non standard release methodology but naming it identically to the standard.
There is no malice here but you have to expect that if you release an RC with something labelled experimental to a group of Linux enthusiasts and dont take time to define whats RC means to you then there is only one outcome to expect.
I strongly suggest the solution to this is to just adopt the standard model. The correct place to discuss more on this is here http://lime-technology.com/forum/index.php?topic=42640.0 and I hope LT and all people complaining join the thread the hammer it out.
-
- get rid of release validation for -rc releases with Basic/Plus/Pro
Does this mean that the "phone home" 'feature' has been removed and that it will start up in the absence of an Internet connection?
That would be my interpretation as well but the new wording for the feature (release validation ) adds just enough doubt to make me want to confirm this as well.
Also CVE-2016-5389 has been ommited from the changelog. Since there is an SSA for this it should be included. Please confirm it is fixed by adding it to the changelog as usual.
-
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.
-
...
Take a look at the Ubuntu policy which IMHO is a shining example of how it can be brief but complete http://www.ubuntu.com/legal/terms-and-policies/privacy-policy
Thoughts?
-
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.
-
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.
-
I am hoping I will no longer be a lone voice in the wilderness.
-
+1 It is pretty unusual we dont have it now. Could this be part of nerd tools?
-
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.
-
Thank you. Glad to see you're considering the removal of a unnecessarily stored data.
Doesn't address the CVE discussion though. Where / when can we expect you to address this?
For the record, I don't appreciate being called a troll.
God news on that front as well
http://lime-technology.com/forum/index.php?topic=42640.0
and
-
As with the other posts this is also excellent and gets another thumbs up.
Two suggestions:
1. You really should consider an addon that lets you push out trivial package security updates. Your Nerd tools package "just works" and in my eyes at least you shouldn't need to build a whole new unRAID OS and ask your entire userbase to install and reboot just to for example update 2 lines within the curl binary which could be pushed out via an addon. I know this is a diversion from the way things are currently done but if nothing more it gives you more time/grace to issue a point release.
2. You do still need a CVE timeline. I would resist any urge to make it short but you need to set the scene for three reasons; if you dont people will just expect you to match whatever their internal policy is and since you havent set one to overide this just opens the door for complainers; also users should know at what point a report will definitely be fixed by, this is a must in any corporate environment; lastly users should know when they have a right to prod or even complain without fear of other users judging them by their own standards. Perhaps 1 month?
-
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.
-
Let's dispel the nonsense. Our Privacy Policy is a section of a larger Policies statement:
Wow look at that. Who would have thought to look in the About:Policy section of a company's webpage for their policies? It is just so crazy of a place that it almost makes sense. Not as much sense as a witch hunt, but ... yeah ... moving on.
Given how much amazing progress has been made over the last 24 hours this kind of comment doesn't help.
I will post more later if I get time but the privacy policy is quite clearly a website policy and not detailed enough to the OS product itself.
Just as an example it doesnt define the scope of the policy.
Take a look at the Ubuntu policy which IMHO is a shining example of how it can be brief but complete http://www.ubuntu.com/legal/terms-and-policies/privacy-policy
-
So in this context would "unRAID-next" be 6.3, 7.0 or 6.2 RC5?
-
Can someone expand on:
...
Slackware64-14.2
We are "in sync" with the recent release of Slackware64-14.2, meaning all unRAID OS packages are either same as in the official Slackware64-14.2 distro or newer. However, in general, we track Slackware64 "current".
...
what exactly does "track" mean in terms of packages? e.g.does it mean all packages are kept on the Slackware64 "current" track or it just when packages are selectively updated they come from the Slackware64 "current" track?
At a guess it means we started with Slackware64-14.2 and cherry picked some package upgrades for 6.2?
-
Alright peeps, this is how much LT care about CVEs and your security. Pretty disrespectful.
This certainly seems like a topic that can never be resolved. For what it is worth RC4 is probably vulnerable to a kernel level MITM CVE-2016-5389. I have not posted this is the security sub forum because what is the point, no one ever acknowledges me and it certainly doesn't impact the timing of a fix.
I think it important we keep focused on what has been asked here because it really is pretty simple; there has to be a privacy policy because unless LT has made a considerable effort not to track personal data the typical name, address, IP, version will be stored in various places. This is to be expected by any online business but thats why a privacy policy is needed.
As for CVEs, I have made my case for this countless times. We need a security patching policy. This is an absolute requirement as due to the "firmware" nature of the product it can ONLY be patched completely at source. This does not need to be much and at its heart is simply a commitment to patch the release product once every XXX days/weeks/months under normal circumstances and an emergeny time line for critical issues. It should also have a basic "report a security issue" privately procedure.
With the exception of the actual patches the above is at most an evening work. As an OS manufacturer it not really optional and certainly to sell in the EU/UK the privacy policy is a legal requirement (luckily its 30 mins effort copying someone elses like everyone else does).
Why cant we simply debate this to conclusion? Why cant we help get it done? I just dont get why its silence or push back every year its brought up.
-
Tom, thanks for the detail breakdown of the cal home in https://lime-technology.com/forum/index.php?topic=51379.msg493097#msg493097
I just wish we could have avoided all this predictable upset by publishing these details at the time the feature was added. It would have turned the whole thing positive and open from day 1 and saved countless man hours.
If this mechanism will be in place for all future beta release cycles i suggest we transplant the words to the wiki.
Kudos
-
unRAID stable fails a basic security audit.
unRAID RC does not.
There is no grey area, there is currently only one secure unRAID version and that is a valid reason for someone needing to run the RC beyond a simple desire for new features or to simply help out.
That is the only point I want to make as it is absolutely relevant here as a counter to the "user opt in choice" arguement.
-
Sorry but you have no choice but to join the beta cycle if you want a secure unRAID patched box.
As we speak the current stable release has over 100 CVE disclosed security issues which are patched in RC.
I do not want to escalate this discussion but I do not accept the arguments that it is just the users choice to join the test cycle and there are no mitigating circumstances.
171 days since the release received a single security patch, an eternity in my occupation.
-
It is not clear at all where it should be discussed because there is no 100% correct place however the RC threads are supposed to be a one-pile-file for everything relating to testing RC which this clearly is.
However the fundamental problem is lots of people are concerned over this and the only people that know the answers, well aren't answering.
Like it or not this will not go away until some actual non speculative information is released. The simple act of trying to curtail this discussion will have the exact opposite effect so lets just endeavour to keep it civil until some details are released.
-
I am not sure it is as clear cut as beta/RC. The last time this was asked LT "reserved the right" to keep it in the live product. (Too busy to find the quote).
My gut is that this was hedging bets but at the same time it adds even more confusion.
Better this is all out in the open, debated and decided once and for all. The current stance is confusing, the information security implications are real and it only leads to this very debate.
Release Methodology
in Security
Posted
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.