Re: commit signing

Re: commit signing

[Jonathan Wakely]

On Wed, 14 Sept 2022 at 10:12, Ulrich Drepper wrote:
> 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).

No opinion yet on the rest of the email, but we already have a script
to set up a git tree for gcc work, so that would be the natural place
to add this:
https://gcc.gnu.org/gitwrite.html#vendor

Re: commit signing

[Richard Biener]

On Wed, Sep 14, 2022 at 11:12 AM Ulrich Drepper via Gcc <gcc@gcc.gnu.org> wrote:
>
> 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.

How does this improve supply chain security if the signing happens
automagically rather than manually at points somebody actually
did extra verification?  That is, what's the attack vector this helps with?

What's the extra space requirement if every commit is signed?  I suspect
the signatures themselves do not compress well.

Richard.

>
> Opinions?

Re: commit signing

[Jakub Jelinek]

On Wed, Sep 14, 2022 at 01:31:06PM +0200, Richard Biener via Gcc wrote:
> How does this improve supply chain security if the signing happens
> automagically rather than manually at points somebody actually
> did extra verification?  That is, what's the attack vector this helps with?
> 
> What's the extra space requirement if every commit is signed?  I suspect
> the signatures themselves do not compress well.

Note, right now we sign the release tags and I think one basepoint
(basepoints/gcc-11) is signed too (but the rest of them aren't).

	Jakub