Verify all signatures and hashes

[garrison]

Following https://github.com/JuliaLang/juliaup/issues/615#issuecomment-1513937160, it is essential for security that the authenticity of any given binary should be established before juliaup installs it. In particular, this means that julia should ensure that a secure checksum of the binary matches its expected value, and it should be possible to verify, through a GPG signature, the authenticity of the file that provides that expected checksum value.

[StefanKarpinski]

How do we distribute, revoke, etc. public keys to verify signatures?

[davidanthoff]

At the moment we rely on the security properties of https for these kind of concerns. I don't see how we can improve security by layering additional protocols on top of that, i.e. it seems to me that if the https layer is breached than all bets are off in any case. I also am not aware of a known vulnerability of https that would bite us right now, unless a client system is compromised (in which case additional stuff also won't help).

I'm also really, really hesitant to start to implement our own security story, instead of just relying on something like https. I am not a security expert, and I think the worst kind of security system is one designed and implemented by someone like me ;)

[garrison]

https is a reasonable starting point, but its main downside is that only a single server needs to be compromised in order for it to host a fraudulent download. Furthermore, there are many, many certificate authorities that are trusted by browsers (see, e.g., this list for Firefox), and it takes only a single one of them to be compromised to result in a fraudulent SSL certificate. This has happened from time to time; the earliest I know of is from 2011.

In cases where a malicious download would result in the execution of arbitrary code on one's computer, it is customary to verify the authenticity of the download before proceeding. For instance, Linux distributions typically provide instructions for verifying the authenticity of the initial download, and they do this automatically when updating packages. Julia's Pkg has mechanisms for doing this too, but I personally don't have a full understanding of how it handles keys. (Stefan would know far more than me.)

I actually just learned that Python's pip, apparently, does not do a full GPG verification of downloaded packages, so take from that what you will. However, in the process of discovering this, I found (via PEP 458) a fairly good resource at https://theupdateframework.io/security/, which has a number of principles for secure software update systems.

How do we distribute, revoke, etc. public keys to verify signatures?

Juliaup can be installed one of two ways: either standalone, or through some app store or package manager. If it is installed through an app store or package manager, then I believe it would be sufficient to include within the installation a list of key(s) that are currently known to be good; any updates to that list of key(s) can be handled as part of the juliaup update by the app store or package manager. Things get trickier in the standalone case, where juliaup updates itself and you have to worry about a bootstrap problem if the key(s) need to be revoked.

I am not a security expert, and I think the worst kind of security system is one designed and implemented by someone like me ;)

Thanks, I think humility like this plays an important role in any good security mindset :).

[davidanthoff]

For now I'm applying the won't fix label. In my mind relying on https is pretty standard and I just don't see that any homegrown solution would be better. Even with my limited experience, I can just think of soo many ways in which any homegrown solution like the one suggested can go wrong, that I'm just really hesitant to go there.

Having said that, if someone wants to really think this through, come up with a complete design and implement it, that would obviously be welcome.

[StefanKarpinski]

That's what I was getting at as well—having a PKI that works is the real problem here and a very hard one.