A lot of software is distributed with PGP keys. These can theoretically be used to verify that the software was created by the person who owns the key. (Sorry if I get the PGP details wrong, I have no practical experience with it.)
Software also comes over HTTPS. With Let’s Encrypt, the verification is tied to ownership of the domain (DNS records I think). So if you’re on ubuntu.com with HTTPS, you’re getting files only approved by whoever owns the ubuntu.com domain.
HTTPS is super convenient. If you’re paranoid, or the entire chain is not HTTPS (HTTPS links to HTTP downloads), you can use a hash program. Hash programs are implemented on all major OSs. It’s visually inspectable.
PGP on the other hand is such a mess that even some cryptographers don’t like it.
What practical threats would be stopped by a PGP key that are not stopped by HTTPS?
✅ plan A
- good guy owns software.org
- encrypts with let’s encrypt (only provided if they prove DNS ownership of software.org)
- https page serves software download
✅ plan B
- good guy owns software.org and has at some point signed a public key
- serves page on software.org with software verifiable with PGP key import
❌ plan C
- bad guy owns software.org
- software is compromised, but you would never know
- software is malware
❌ plan D
- bad guy owns software.org
- did not compromise the public key (created years prior by the true owner)
- they cannot distribute software that matches the public key
- software is malware, served over valid https, and verifiable with malware hashes served by bad guy
One thing I’ve never understood about providing a hash for the download, is that the download and the webpage displaying the hash are typically served from the same domain, so if the download is compromised, couldn’t the hash be too?
oversimplifying a bit:
TLS (https) provides transport security that whatever is served by the mirror is really associated with the domain name for that mirror domain name. Each HTTPS response is signed live so the private key must be “hot” and loaded in memory on the mirror (or its reverse proxy).
PGP signatures provides integrity and authentication that the package files themsvelves have been signed by the repo signing key. This signing can be done once per package and the private key can be offline.
HTTPS is not a replacement for PGP sigs. They are for different things. HTTPS will provide a bit better privacy (and now that I think of it, theoretically some package manager could be vulnerable to downgrade mitm - substitute a package with a legit and signed but older vulnerable version - or other bugs).
PGP on the other hand is such a mess that even some cryptographers don’t like it.
I’ve seen plenty of critique on PGP for email encryption but that’s not relevant here.
sq(sequoia) is great alternative implementation you can use instead of GnuPG.So you trust every single mirror to never be compromised?
HTTPS is super convenient. If you’re paranoid, or the entire chain is not HTTPS (HTTPS links to HTTP downloads), you can use a hash program.
How do you verify the hash?
You have it approximately right, serving from an https domain does nothing to authenticate the thing being downloaded. There is such a thing as signed downloads, authenticated by a “code signing certificate”, used for things like Windows installers. Linux distros tend to use PGP signatures instead. Signing the download can in principle be a more secure process than serving a domain over https, since servers get pwned all the time. The download signing, by contrast, can in principle be done completely offline. There is a catch to that involving connecting to a timestamp server, but that gets into the weeds.