Sign arbitrary data with your SSH keys

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

[2] https://guix.gnu.org/en/blog/

> Since .guix-authorizations is a regular file under version control, granting or revoking commit authorization does not require special support. In the example above, commit B is an authorized commit by Alice that adds Bob’s key to .guix-authorizations. Revocation is similar: any authorized committer can remove entries from .guix-authorizations. Key rotation can be handled similarly: a committer can remove their former key and add their new key in a single commit, signed by the former key.

I'm unaware of the implementation details, such as whether git will validate sigs for a PGP key which has been revoked. That's a fair question, although for this usecase i can't imagine how it would be useful to deny signatures from the entire project's history because a key has been revoked.