I agree with your concern. As a temporary "workaround" I've updated the article with a SHA256 checksum of the key. I'll chase the Nginx team for serving this key over https

We should really be verifying the fingerprint of the key itself, even if it is served over HTTPS.

Thanks for the update!

Note that it also does not limit the key to simple nginx packages - if I take control of that repo I could trick you into installing my version of, say, base-files or bash, etc.. :(

Unfortunately, it seems there's no secure way to fetch the key. The nginx team recommends one checks the "web-of-trust" to check if the key is signed by others.

At the least though it could be https.

I also suggested that in the meantime the author of the article can provide a SHA256 checksum, so you can see if you get a different key than he does.

Stick it on a keyserver, and then ask gpg to fetch it from that keyserver with the full fingerprint. Assuming that your instructions that include the fingerprint are secure (which they have to be, else the instructions could root your box anyway), then that should be reasonable.

This does assume that gpg verifies that the key retrieved matches the ID requested, which I assume it does. Otherwise that'd be quite a serious bug.

The question is how to ensure you're getting the right fingerprint. If you have that, you can just as easily fetch the key using HTTP and verify it.

I covered that when I talked of the security of the instructions. The real question is how to ensure you're getting the right instructions, since they could direct you to download a different source entirely.

If you have ensured that you're getting the right instructions, and those instructions supply the right fingerprint, then you can be sure that you have the right fingerprint.

Based on the PGP pathfinder here[0], it is likely this is a valid key. I'm only a few signatures away from this nginx signing key.

[0]http://pgp.cs.uu.nl/

The problem is that "this" changes depending on who runs your network. You see the correct key, but I might not.

Also, while apt-key might handle random input fine, I'm concerned with anything that goes "curl http://example.com | sudo ...". In this special case, "apt-key add -" should avoid most problems - but I'd still prefer verifying the (possibly untrusted) gpg-key as a normal user, and then elevating to add what appears to be the correct key, and a valid gpg-key via apt-key add.

What bugs me is how prevalent that has become.

I'm looking at you Jenkins![0]

[0] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenki...

Jenkins at least serves the key over HTTPS. Would you instead prefer they did not offer packages for your package manager at all? I sure wouldn't, I really appreciate those packages for easy upgrades.

I would prefer if they made it easier for people to verify the gpg key fingerprint for those of us who want that extra level of security. You don't have to verify the fingerprint if you don't want to but at least give me the option.

The rust project also advocates this method of installing software on their download page. To their defense, however, they do offer gpg signatures for their tarballs, even if you need to dig around for a bit to find them.

Also, anyone suggesting that this method of downloading and installing software is secure due to its use of HTTPS is incredibly reckless.

There's a ton of important software that people are installing over HTTP, so using HTTPS is unfortunately already super-substantial progress. Chris Palmer gave the sad example of PuTTY a couple of years ago:

https://noncombatant.org/2014/03/03/downloading-software-saf...

(after what I think was a long time, the actual download links themselves are now HTTPS, although they're all still served -- along with the signatures -- from an HTTP page)

I'm certainly not going to defend the idea that HTTPS is enough authentication for software installations (I'm writing an article related to software transparency), but there's a pretty big bootstrap problem and infrastructure gap right now.