commit signing

[Ulrich Drepper <drepper@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]

For my own projects I started /automatically/ signing all the git commits.
This is so far not that important for my private projects but it is
actually important for projects like gcc.  It adds another layer of
security to the supply chain security.

My shell prompt (as many other people's as well) shows the current git
branch but in addition also shows the validity of the signature if it
exists.  For this a file with the authorized keys needs to be provided.

I found it easiest to use SSH keys for signing.  One can create a new key
for each project.  If the desktop environment uses GPG daemon or something
like that one doesn't even realize the signing request, it's handled
automatically.

git allows to set up signature handling on a per-project basis.  I.e., no
decision made for one project will have any impact on other projects.  For
painless operation all that is needed is that the authorized keys are
published but that's not a problem, they are public keys after all.  They
can be distributed in the source code repository itself.

My question is: could/should this be done for gcc?  It's really easy to set
up:

- create new key:

  $ ssh-keygen -f ~/.ssh/id_ed25519_gcc -t ed25519

  (of course you can use other key types)

- configure your git repository.  This has to be done for each git tree,
the information is stored in the respective tree's .git/config file

  $ git config gpg.format ssh
  $ git config user.signingKey ~/.ssh/id_ed25519_gcc.pub
  $ git config commit.gpgsign true
  $ git config tag.gpgsign true

  If ssh-agent is not used then the user.signingKey must point to the
private key but this is hopefully not the case for anyone.  It's also
possible to add the entire key to the configuration, which doesn't
compromise security.

  It is possible to define global git configurations (by adding --global to
the command lines) but this means the settings are shared with all the
projects you work on.  This can work but doesn't have to.

- collect all maintainer's keys in a public place.  There could be in the
gcc tree a file 'maintainer-keys'.  The file contains one line per key, the
public key preceded by the respective email address.  If this is the case
use

  $ git config gpg.ssh.allowedSignersFile maintainer-keys

  At least the original git seems to be happy with relative paths (i.e., if
the file is not at the toplevel an appropriate path can be added)

  Every maintainer then just has to remember to submit any newly created
key as a patch to the 'maintainer-keys' file.  That's it.

The key creation ideally is a one-time effort.  The git configuration is
for everyone using the gcc git tree a once-per-local-repository effort (and
can be scripted, the gcc repo could even contain a script for that).

After this setup everything should be automated.  Someone not interested in
the signature will see no change whatsoever.  Those who care can check it.
Note, that github also has support for this in their web UI.  CLI users can
use

  $ git config log.showSignature true

to have git display the signature state in appropriate places by default.

If and when signatures are universally used one could think about further
steps like restricting merges based on trust levels, add revocation lists,
Or even refusing pushes without a valid signature.  This would indeed mean
a higher level of security.


Opinions?