fstelzer

Afaik 1Password simply provides an ssh-agent. So I don‘t see why this should not work. If you set gits user.signingKey to your public key and have SSH_AUTH_SOCk point to 1password agent this should work. Do you have any details on why not?

You can configure which key to use when signing your work https://git-scm.com/docs/git-config#Documentation/git-config...

i see that the docs are missing info on ssh there still. i will update this since with 2.34 you can also specify a ssh publik key literally in this variable or point it to a file with it.

I think one of the most compelling reasons of using ssh for signatures is the possibilies of ssh-agent and especially agent-forwarding which allow for incredibly portable workflows like ssh to a ci/build host/container to sign some production binary/container/tag.

Please note that these come with their own pitfalls and precautions you'll need to take to ensure your key's safety!

If you consider agent forwarding i'd recommend use of "ssh-add -c" to have your agent at least confirm every use of your private key. Generally for private key security i'd always use a hardware token. Modern yubikeys are really easy to use and you can even enable touch policy instead of the agent confirmation. The UX for this is still a bit lacking in the tooling though.

I think if you trust your maintainer/central tool enough to merge code from your developers then i think you can also trust them to verify all the commit signatures they receive and then resign the resulting merge right? After all they could simply create all the commits they want themselves right? The authors commit signature from before the merge will be lost. If you use signed tags though the merge will retain the initial signature on merge in the merge message.

btw. i am also a great fan of the phabricator workflow :)

Correct. Linking an identity to the crypto signature is the hard part for every mechanism. Regarding the allowed signers file you have several options:

A repository only allows signed commits / merges / pushes and simply stores the file in the repo itself.

If you already rely on forges like github/gitlab/... and trust them to generate a file for you (e.g. from the users ssh keys having write access to the repo).

You maintain this file independently for yourself with a "Trust on first use" mechanism (which will follow in a future patch to git)

A git patch currently in progress will utilize the valid-after/before options that you can set on keys in this file to verify the commits/tags with keys valid at the time of the objects creation. This will allow for key rollover and still being able to verify old signatures. (Theres also the revoke file which will invalidate all signatures for a key). In addition to that a "trust on first use" patch will follow that can automatically add new keys with the committers ident to this file (unless the ident is already present with a different key of course, which should error badly).

disclaimer: i wrote the git integration for this