NAS

https://curl.haxx.se/mail/lib-2016-10/0076.html Bad timing since its so soon after 6.2.2

Nice one ! Can these be native?

I would like the ability to manually upgrade all containers with a single button press. I believe updates can be scheduled, but for me at least containers need to be upgraded when a human is around to test immediately afterwards.

Uhh thousands of people upgrade Windows/OSX probably daily without reading anything about it. Those upgrades handle incompatibility and let the user know about it. I get what you are saying but that was a terrible analogy. Since we now have a button that upgrades in-app I don't think its fair to assume that means people should still know to go read and announcement thread. We have been conditioned that both app and OS updates are virtually seamless for everything nowadays, Windows, OSX, Android, iOS and all the apps within them. This is a fair point. I do not remember being told by the web gui that I "now need to go other stuff manually".

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

Version string. Long slow clap on that one alone. Nice work.

Excellent clarifications, we need to make sure this information is promoted to the actual policy. Something I now realise when i read your "Look, people seem to think we are "gathering info on them" reply is that no one has actually said out loud that the USERS primary focus on this is almost certainly not directed at LT themselves. It is the information that can be lost by either a accident, breach or by direct legal request. This is when "cross referencing" comes into play where an attackers or agency data mines and relates all information to either exactly describe a vector or estimate one e.g. James from Iowa purchased unRAID with IP X and hostname Y. Forum logs shows Jane has similar IP. Jane is probably an alias of bob. Google mining says Jane also uses forum Y etc etc etc From a COMPANY standpoint the less you track the better as it is all stored at your liability and is why full disclosure is needed to mitigate both risk and PR issues should something bad happen. But I will comment directly on this, "All the info we "gather" is simply made available by anyone using the internet,". unRAID is not just a random website you are the purveyor of an entire operating system and have a much larger privacy burden than almost any other computer product in existence.

We have updated our Policies page with more details regarding Privacy: https://lime-technology.com/policies/ Since it is not on the wiki I cannot see change control, however to my eye this is really starting to take shape. Glaring omissions: Retention (what and how long you keep all data and if different for stale data) Law enforcement. Who can request information, under what circumstances and what legal system the privacy policy operates under. Online Update section contains no information on what is passed and stored I still have some concerns because if you look at the data being stored end to end we have: name billing address e-mail address (multiple) time limited credit card/paypal information which may include alternate contact details IP address through which the registration is initiated IP address through which products are purchased IP address of forum access IP address of feedback IP address of update checks GUID of the USB flash device at at purchase, trial run and update (TBC) This is a lot of information and quite a bit of cross referencing could happen to keep the relationships fresh and relevant. Note: Comments made based on the actual current wording.

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

Can I suggest that this thread is closed and the security policy be merged with the release methodology since they are essentially the same in term of unRAID as an appliance.

nice work that man

Agree

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 and a further issue 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.

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.

My final word on this, given the amount of confusion the current wording is not suitable and clearly has to be changed. Necessitating users refer to a manual to understand a state selection is a design fail.

Really? So the logical deduction, from what you state, is that one of the options is superfluous. If that were really the case, any true IT professional, based on logic and minimising complexity, would have eliminated one of the options in its infancy. Admittedly, I'm retired from professional IT, but my experience has always been that 'on' means ON, 'off' means OFF and 'auto' means that it is either ON or OFF, dependent on some other factor. My little home project, at the moment, is a domestic lighting control system - lights can be turned ON or OFF by a manual switch, or they can be set to 'auto' whereupon the system decides whether to turn a light ON or OFF, dependent on time of day, or ambient light level or other factors. If 'auto' meant always on, the system wouldn't be very functional. Reading what you wrote and I think I agree with you that when I say "Auto on" in my head what I am really saying is "Auto on when needed" which does imply if you think it through that it starts from an off state. However if someone was to ask me the other way around to choose a word that describes this behavior I would never choose "Auto" I would almost certainly choose "Dynamic". Like above this made me realise that my default mindset for this is on "manually enabled", off manually disabled" and auto "Automatically start". The difference being a one time even and not a dymanic thing (think windows services for a better example). Thanks for the informal poll though I would have predicted those results but given the strong cases either way I started second guessing. This just proves why you need a beta cycle, even the most obvious thing can generate bugs

I really dont want to post about this but I feel I have to. Two points: In my life long experience when faced with an "on/off/auto" choice then auto means on. It would not occur to me that it may mean anything else than this. I even subconsciously say "auto on" in my head. Is it wrong that it could mean something else, well no, but good design always start from a point of intuitive understanding. We need to stop using terms the industry have used for decades to mean one thing and then try to teach the world they mean something else to us. This is a prime example of why you dont add new stuff in an RC. We now have last minute confusion needlessly that could easily have been handled in the 6.3 cycle.

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.

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.

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.

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

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.

Thoughts?