On 03/07/2014 05:42 PM, Tres Finocchiaro wrote:
 that is must be absolutely secure. No compromises, no excuses, it MUST be secure: we can't just put a server address there that LMMS checks - it must be future proof (what if our server address changes? well, the users will get the new one in the next update... oh wait), so there must be some kind of foolproof authentication scheme, so that if someone manages to spoof our server or do a man-in-the-middle attack or something, LMMS will know "this isn't our real website, something is up, let's bail".

Well, to be fair, there's no such thing as absolutely secure.

Doesn't matter at all. If we start implementing features like this, security MUST be a top priority. That's why I got to ask whether this feature is worth all the trouble? I'd rather LMMS didn't connect to networks at all - as it would save us from all the security problems.

I believe what you're referring to is using some form of certificate verification (MD5, which is fairly secure gets ruled out for downloads since we can't see into the future!)

MD5 is not secure, it's been proven vulnerable. SHA256 is widely considered its successor. Also, MD5 is a hashing function, we can't predict what the hash of a release we haven't released yet would be.

What we need is more like PGP or RSA keypairs.

Self-signed scenarios:
  • The current software contains the public key in it's source code and verifies the update is signed with the the private-public chain.
    • Pros:  No expensive trusted root certificate is needed, download is verified against a known "trusted" source.
    • Cons:  Anyone can compile their own version with a different public key.  If the software were installed from an unofficial source to begin with (and therefor a different public key), it would flag the good software as bad, or worse look elsewhere for updates and dangerously flag those locations as good.

Not our problem! People should NOT trust third-party installers in the first place. That's out of our hands, we can do nothing to guarantee the security of binaries compiled by other people in the first place. 3rd-party binaries can contain all kinds of malware, spyware, viruses... and we can't do anything about that, apart from telling our users to only trust trusted distributors.

    • Cons:  The private key could not be part of the public domain.  Instead there would need to be a "trusted group" of people keep this behind locked doors.

How is that a con? That's pretty much just a prerequisite of any security feature.

    • Cons:  Key expiration would eventually happen and if the private key were accidentally stolen, no revocation information would be available.

"Key expiration" is only a thing if we want it to be. As for the private key, we'd just have to take good care of the private key. Never store it online, don't send it over emails, only store it on secure computers. Yes it's possible for a private keys to be stolen, but that mostly happens when someone is being stupid.

Trusted-signed scenario:
  • Same as above, except revocation information *would be* available.
    • Pros:  The chain of trust comes from a centralized authority with good revocation info.

Uh... that's a con, actually. There is no centralized keysigning authority that we could trust.

So a claim that "it must be absolutely secure. No compromises, no excuses, it MUST be secure" is a noble but impossible requirement.  There's no such thing as security without compromises.

Which is why we should seriously consider whether this feature is worth implementing.

Furthermore, in one breath to say "my word isn't the law on the subject" and then in another breath to use all caps with the word "MUST be secure" is the very passive-aggressive wording that IMO discourages open ideas from flowing. NO SHOUTING! :)

Any software that connects to a network MUST have security considerations. That's just a fact of life. On Linux, we do it by trusted packagers and package managers, which btw also have authentication schemes in place to make sure the package repositories aren't compromised or spoofed.

That said, I see very little harm in checking a mirror for a download link and displaying that in the help area.  Can someone spoof that DNS? Yes.  Can someone provide a virus at that address?  Yes.  Can someone ask for Paypal login information?  Yep.  Can all of this happen when you click on your normal web browser and type in lmms.sourceforge.net?  Yep.  The risk is up to the community and so as long as there is no warranty and we explicitly as the user to waive liability on install, I'd argue we are no worse off than we would be if it were an email or a Facebook link that offered a new version.

We can't do anything to web browsers. Browsers have other security mechanisms in place - mozilla and chrome both already have contingencies in place for situations like that - blacklists, security warnings, etc.

We CAN do something to a feature that's in our control, in our software. And a feature in our software would not have those existing security measures that browsers already employ. So no, we can't just say "whatever" and half-ass it. When it's the user's security in question, we can't take chances. That's simply not acceptable. When a link is in our software, users will expect it to be secure. So it has to be secure, period, end of story.

Your argument is basically a big logical fallacy: "we can't make it absolutely secure, so we might as well just not bother." That's not how it works. The perfect should not be the enemy of the good. Just because we can't make a 100% guarantee, is not a reason we shouldn't strive to make a 99.9% guarantee.