On 03/07/2014 05:42 PM, Tres
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
address changes? well, the users will get the new one in the
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
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
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.
- The current software contains the public key in it's
source code and verifies the update is signed with the the
- Pros: No expensive trusted root certificate is
needed, download is verified against a known "trusted"
- 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
- 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.
- Same as above, except revocation information *would be*
- 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
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.