unRAID "Phone Home" discussion

[jumperalex]

you may need to update to the latest RELEASE, but you do not need to update to the latest BETA or RC unless you intentionally jump on that path. And when you do, because maybe you really want to be a part of the discussion to drive change, then you better understand the risks and limits.

 

And perhaps be prudent and make sure you have a way back to the most recent stable release for a production server. Read: wanna try new hardware that is only functional in Beta/RC, do it on a test server, accept the risk, or don't do it.

[NAS]

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.

 

 

[jbartlett]

Are the 100 CVE disclosed security issues mitigated by not exposing your UNRAID server to the Internet? If I recall, such exposure has been widely regarded as a very bad thing by everyone at all levels.

[jbartlett]

I would argue the security patching is a red herring in this topic as it has always been an issue and always will be an issue until UNRAID supports inline patching that has to be reapplied at every boot.

[jumperalex]

Every single product out there has the potential for security patches that are not pushed to the current release version for X time while they are being tested in Beta/RC.

 

If you want to debate the length of X for a vulnerability related to its likelihood and consequence (i.e. the definition of risk) Ican get on board with that. I know it is a hot button with you and I've often agreed with you in other threads. But a blanket statement that you have to be on the Beta/RC train to get all patches isn't black and white.

[NAS]

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.

[navvy]

What data are you collecting? (A file by file breakdown will do to begin with)

A fair question. One Im' pretty sure has been answered long ago but I don't have the time or patience to search for it so yeah, it would be nice for LT to state it again

Pretty sure this has never been answered and as I said in the other thread and it was deleted, not moved, a response on what of my data is being sent to LT and is it being stored should be the minimum response from LT. I don't think that's unreasonable.

[ironicbadger]

Are the 100 CVE disclosed security issues mitigated by not exposing your UNRAID server to the Internet? If I recall, such exposure has been widely regarded as a very bad thing by everyone at all levels.

 

Depends what else is vulnerable on your network that IS exposed to the internet. Ever heard of island hopping? Sounds implausible until you think about the multitude of Internet of Things devices that are beginning to sit on our LANs. These devices often don't get patches and are nice little ingress points for those that are looking. There are whole podcasts dedicated to this topic, TechSNAP for one. This is people's entire livelihoods - security.

 

You know, NAS, I hadn't even considered the security angle but by jove - that must be the best one in this thread by a mile. Ethics aside for a second, the integrity of your data is what this whole thread is about (right?). Please explain to me how leaving a box vulnerable for so long can possibly have your users best interests at heart? There are many processes in place for responsible disclosure of vulnerabilities from proper vendors so that their users can update the *second* a CVE is disclosed. This was the fundamental reason grumpy and I pestered Tom for so long to put unRAID on top of a 'proper' OS and let users have a proper userspace. This is all preventable. Linux (as a whole) has been solving this problem since before Ross and Rachel were on a break... Come on LT!!! Patch your S - or change architecture. It's the responsible thing to do.

 

The time it takes to make a coffee. That's how long this issue would take to put to bed, unless there's something to hide. 

[jbartlett]

Ironicbadger: You're not still holding a grudge against past interactions with LT that did not favor the outcomes you desired? There's a very clear anti-LT theme to all of your posts.

[ironicbadger]

Ironicbadger: You're not still holding a grudge against past interactions with LT that did not favor the outcomes you desired? There's a very clear anti-LT theme to all of your posts.

 

To all of my posts? The one's in this thread, perhaps yes. For the reasons stated and those alone. What happened 3 years ago is ancient history now, and I don't believe I ever 'fell out' or rage quit either. BTW, LSIO is a huge contributor to the unRAID ecosystem in case you'd missed that!

 

I don't mind eating humble pie if and when the time comes, by the way. Just find it interesting when premonitions come true - honestly that is all. A call to action is an entirely appropriate response in my opinion under the circumstances. As a more technical user, comfortable with compiling kernels and tinkering away in the very bowels of Linux systems on a daily basis, I simply expect LT to talk to their customers when a thread like this 'blows-up' and feel somewhat duty-bound to highlight issues such as these to those who might not understand quite what is at stake. I owe a great deal to unRAID for pushing Docker so early as it's now my livelihood (despite, I might add, my protestations to the contrary). Sometimes they get it right, sometimes not. In my opinion this is not a time where things are right.

[trurl]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

[navvy]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

Ok, so maybe it got lost in the forum shuffle.  Fine.

 

Not my main point, I still think disclosure of what information is being sent, how/where it is being stored, what it may/is being used for are reasonable questions.

 

I think all the rhetoric would dial way back if people got a straight answer on this one.

[trurl]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

Ok, so maybe it got lost in the forum shuffle.  Fine.

Not to belabor the point, but it would be nice to know if it is actually possible for the forum software to lose something like this.

 

You don't have that many posts, and about half of them are related to either this thread or the other. Please check your post history and see if the post is there.

[CHBMB]

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.

 

Just playing devil's advocate here, but Unraid has, as far as I know, always been sold as an "insecure" os, so whilst security concerns are very valid and in my opinion becoming more and more important in recent times, and which may well require a rethinking of long term development strategies, but as we stand today Unraid has never made any claims that it is secure.  So there's somewhat of a disclaimer regarding the lack of rolling security updates.

 

 

[CHBMB]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

navvy I'm happy to say that I 110% don't believe trurl would ever delete a post.  13 posts and you should be able to find it, but casting aspersions on a mod who is just about as impartial a man as one could "meet" is not right.

 

Hell he even sent all that spam to bilge rather than wiping it from the face of the earth.... 

 

[sparklyballs]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

navvy I'm happy to say that I 110% don't believe trurl would ever delete a post.  13 posts and you should be able to find it, but casting aspersions on a mod who is just about as impartial a man as one could "meet" is not right.

 

Hell he even sent all that spam to bilge rather than wiping it from the face of the earth.... 

 

 

i was feeling peckish and ate the posts, they looked like biscuits , but they didn't taste like them

[navvy]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

navvy I'm happy to say that I 110% don't believe trurl would ever delete a post.  13 posts and you should be able to find it, but casting aspersions on a mod who is just about as impartial a man as one could "meet" is not right.

 

Hell he even sent all that spam to bilge rather than wiping it from the face of the earth.... 

 

 

i was feeling peckish and ate the posts, they looked like biscuits , but they didn't taste like them

 

I didn't accuse him of anything.  I even gave him the benefit of the doubt.  I don't know trurl and made no judgement against him, I was trying to finish that part of the discussion so we could get back to the point.  If my comment was taken that way I do apologise, it wasn't how it was meant.

 

And I don't know how 13 posts is relevant.  That would be a blind judgement made on your part.  You know nothing about me, my experience or skill level.

 

I think we do need to dial it back and stop leaping to conclusions.  My question is still: Can we get more information about what is sent?  Can we find out how/if it is stored?

 

To me this is a bigger concern than what LT may or may not do in the future.

[CHBMB]

... as I said in the other thread and it was deleted, not moved...

I absolutely did not delete any posts.

 

navvy I'm happy to say that I 110% don't believe trurl would ever delete a post.  13 posts and you should be able to find it, but casting aspersions on a mod who is just about as impartial a man as one could "meet" is not right.

 

Hell he even sent all that spam to bilge rather than wiping it from the face of the earth.... 

 

 

i was feeling peckish and ate the posts, they looked like biscuits , but they didn't taste like them

 

I didn't accuse him of anything.  I even gave him the benefit of the doubt.  I don't know trurl and made no judgement against him, I was trying to finish that part of the discussion so we could get back to the point.  If my comment was taken that way I do apologise, it wasn't how it was meant.

 

And I don't know how 13 posts is relevant.  That would be a blind judgement made on your part.  You know nothing about me, my experience or skill level.

 

I think we do need to dial it back and stop leaping to conclusions.  My question is still: Can we get more information about what is sent?  Can we find out how/if it is stored?

 

To me this is a bigger concern than what LT may or may not do in the future.

 

13 posts was no comment on ability, skill or experience, merely that it's easy to search back through the history, which is what I thought I said.... 

[navvy]

13 posts was no comment on ability, skill or experience, merely that it's easy to search back through the history, which is what I thought I said.... 

 

See, I'm guilty of having my own over-reactions too.  Apologies, I think this whole topic is putting people a bit on edge.

 

Hopefully we can get a few official answers and put this thing to bed.

[CHBMB]

No problem, I was just trying to quench some fire.... 

[Squid]

13 posts was no comment on ability, skill or experience...

Or 4534

[CHBMB]

13 posts was no comment on ability, skill or experience...

Or 4534

 

Exactly....  Post count is meaningless, and the longer I'm here the more I realise that.  I gave up a long time ago linking post count to ability. 

[jwegman]

Exactly....  Post count is meaningless, and the longer I'm here the more I realise that.  I gave up a long time ago linking post count to ability.

 

*AND* I consider the same is true for multiple posts from the same individual(s) in a single thread hammering on a single point to be just as meaningless   I'm not calling anyone out here, you all know who you are.  Say your peace and let others respond.  Consider what has been stated by others, then if you have something new to say, contribute it, otherwise chill out.  Easy concept, right?

[limetech]

Here's the "phone home" request:

 

/usr/bin/curl -s --retry 3 --data 'version=<unraid-version>&guid=<flash-guid>&token=<random>' 'https://keys.lime-technology.com/time'

where,
  <unraid-version> is the version string as displayed in /etc/unraid-version, e.g., "6.2.0-rc3"
  <flash-guid> is the USB Flash device GUID
  <random> is a unique random string

 

The key-server returns a 256-byte encrypted block similar to registration keys.  Its contents consist of a string:

 

'currTime=<time>&token=<random>'

where,
  <time> is the current time-of-day according to our key-server
  <random> is the same random value sent in POST request

 

We send up the USB Flash GUID because we want to keep track of how many active servers are out there still running Trial, and in the case of beta/rc, how many servers are running beta/rc.  The former is a business metric, the latter is a development metric (to see how much testing is happening).  We're not gathering any personal info because with Trial there is no personal info (other than an email address to which we sent the Trial key initially).  In the future we may send up other stuff, such as the hardware config, but this would be an opt-in program.  Note that I believe something like wireshark can display what is being sent to the server, but I don't really know.  The intention is not to hide information being sent up, it's simply to ensure that the key-server is not being spoofed.

 

We don't really need <random> - it was in there for when 'http' protocol was initially used in the first betas to connect to our key-server (to verify system is really talking to the limetech key-server), but since we now use 'https' it's not really needed.

 

The <time> value is used to validate the Trial key time period, with one special setting: if zero, that means the release version has been withdrawn.  So far I don't think we have invalided any releases.  So why have it?  Go do a 'diff' of md/unraid driver from 6.2-beta/rc and what you find in 6.1.9.  Some of that coding is pretty hairy and I'm a paranoid S.O.B., especially after the ReiserFS fiasco.  A release that gets out there and destroys a bunch of user data is far more damaging to us than the ravings of a few in this thread.

 

The history of the "phone home" was that we initially wanted a better Trial experience.  With dual-parity it just doesn't cut it to give someone only 3 devices.  Many people wondered why we had both a time-limit and device limit anyway, so we've ended up eliminating the device limit and now only have a time limit (though with extensions possible too).

 

So the "phone home" was initially designed to implement time-limited Trial.  But then it takes about 5 minutes to realize you can use same mechanism to validate releases (or rather to invalidate them).  Maybe we should have ended this requirement with start of -rc phase.  One could make a pretty good argument for that.  It was my decision to leave it in for -rc because with -rc we were anticipating much wider participation, and thus more opportunity to discover data-destroying bugs.

 

The one thing I will apologize for is the looong release cycle.  6.2 'stable' should have been released months ago.  We all on the development team realize this must be addressed.

[navvy]

Thanks for the answer.  That all sounds good.  Now my tinfoil hat can be put away again.