I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either
https://docs.github.com/en/authentication?query=public+key+u...
I had a different concern... if people eventually start to use SSH keys to sign git commits, (as the article suggests will soon be possible), people can't validate github commit sigs with github public keys directly at one point in time... because if one is compromised, so is the other.
The only way github could be used as key distribution for this purpose would be if individuals take (and keep) a copy of every public key they are interested for future verification in-case an attacker changes it. But then I guess any public key distribution system has this problem??
So if the repo has that file, and as long as you don't allow history rewrite when pulling (disabled by default), you can be pretty confident all commits have been signed only by authorized keys from the point you checked out initially.
About bootstrapping, several strategies are possible:
- [crev](https://github.com/crev-dev/cargo-crev) is an alternative (not PGP/SSH based) web of trust for vetting code
- [radicle](https://radicle.xyz/) is a p2p forge to do away entirely with web-based centralized forges (like github)
- we could imagine a sort of public-key-addressed DHT where a forge (such a Github) advertises the public keys of its members, for example based on IPNS (although a history-preserving system would be better)
- of course source-based distros like NixOS and GNU/guix are also a very good answer about bootstrapping trust in the code you run ; guix in particular does intensive research and development about bootstrappability and reproducibility [1] which you can read about on their blog [2]
Shameless plug: i wrote an article earlier this year about some of the challenges surrounding decentralized forging: https://staticadventures.netlib.re/blog/decentralized-forge/
[0] https://guix.gnu.org/en/blog/2020/securing-updates/
[1] I'm personally really amazed and slightly disappointed by both: they're really cool on paper, but although guix has a much better CLI UX than nix (and in my opinion Guile Scheme is much easier than nix programming language), both have very cryptic errors