commit signing

commit signing

[Ulrich Drepper]

[-- 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?

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

Re: commit signing

[Ulrich Drepper]

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

On Wed, Sep 14, 2022 at 1:31 PM Richard Biener <richard.guenther@gmail.com>
wrote:

> How does this improve supply chain security if the signing happens
> automagically rather than manually at points somebody actually
> did extra verification?


It works only automatically if you have ssh-agent (and/or gpg-agent)
running.  I assume that's what developers do anyway because that's how they
like push changes to sourceware.  If you don't have an agent you'll have to
provide the signature of the signing key at the time of the commit.


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

The signatures are probably implemented as signed hashes of some sort.  So,
perhaps an additional SHA256 block plus infrastructure to determine the key
used etc.  I doubt that this is really measurable with today's disks and
servers and network connections.

Re: commit signing

[Ulrich Drepper]

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

On Wed, Sep 14, 2022 at 2:07 PM Ulrich Drepper <drepper@redhat.com> wrote:

> On Wed, Sep 14, 2022 at 1:31 PM Richard Biener <richard.guenther@gmail.com>
> wrote:
>
>> How does this improve supply chain security if the signing happens
>> automagically rather than manually at points somebody actually
>> did extra verification?
>
>
> It works only automatically if you have ssh-agent (and/or gpg-agent)
> running.  I assume that's what developers do anyway because that's how they
> like push changes to sourceware.  If you don't have an agent you'll have to
> provide the signature of the signing key at the time of the commit.
>


This was the last message I sent and no further questions or comments
arrived.

Shall I prepare a small patch with an initial version of the key files
(with my key), perhaps a patch to the setup script Jonathan mentioned, and
a few words to be added to a README or similar file (which?)?

Initially this could be optional and we could gather data on the pickup and
only after an initial period switch to make the signing mandatory.