From the blogpost i linked:

> 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.

This seems like it would work, but requires a centralized point to enforce it. Otherwise, it seems that you could trigger a "split brain" scenario where in one repo a key is revoked by a malicious user, and in another the malicious user's key is revoked (or development continues). Which lineage is correct?