Question about EDK2 and commit signing


Pedro Falcato
 

Hi everyone,

Yesterday, when pushing my first commits to edk2-platforms (as the
Ext4Pkg maintainer), I noticed that my commits (see 7872c98 and
71f3343) stick out like a sore thumb, as I have GPG signing on my
commits on by default (see git config commit.gpgsign), globally across
all my projects.

Is there an official stance on signed commits? I was thinking that
commit signing, at least for the maintainers that apply and push
patches, could be useful as a way to establish authenticity for every
commit that gets to the edk2 repos.

Best regards,

Pedro Falcato


James Bottomley
 

On Sat, 2021-09-11 at 19:25 +0100, Pedro Falcato wrote:
Hi everyone,

Yesterday, when pushing my first commits to edk2-platforms (as the
Ext4Pkg maintainer), I noticed that my commits (see 7872c98 and
71f3343) stick out like a sore thumb, as I have GPG signing on my
commits on by default (see git config commit.gpgsign), globally
across all my projects.
They do? The gpgsig header is eaten by modern versions of git ... it
only shows up as the verified decoration on github, which most people
likely don't notice, because github has a huge amount of commit bling,
so I'm not sure what you think people would notice. I suspect even
ancient versions of git understand it's a header even if they can't
parse it.

Is there an official stance on signed commits? I was thinking that
commit signing, at least for the maintainers that apply and push
patches, could be useful as a way to establish authenticity for every
commit that gets to the edk2 repos.
The general consensus over at the Linux Kernel, which is an email based
project like edk2, is that signed commits don't add anything useful.
They can't be transmitted from the author in email, so they can only be
added by the committer. In the current trust model, the committer is
already trusted with access to the tree, so a signature doesn't add
much beyond what's already known (the committer did this) and it can't
add anything further about the authenticity of the actual commit if
author != committer. The other problem with signed commits is there
are lots of usual git operations (like rebase) where the signature
doesn't survive.

James


Marvin Häuser
 

Hey,

Just my 2 cents...

Contributors: Git's stance is the author doesn't really matter as long as the code is acceptable. For most people, you will not know them anyway and it does not buy you much to know they own GitHub account XY. If someone is impersonating a maintainer (who would push the changes directly after review), that would be obvious anyway.

Maintainers: Why would someone have access to your SSH key but not your GPG key? Especially if your commits are auto-signed, both keys are likely equally readable. More factors do not meaningfully increase security if they are not clearly separate.

I'm sure nobody minds your signatures though. :)

Best regards,
Marvin

On 11/09/2021 20:25, Pedro Falcato wrote:
Hi everyone,

Yesterday, when pushing my first commits to edk2-platforms (as the
Ext4Pkg maintainer), I noticed that my commits (see 7872c98 and
71f3343) stick out like a sore thumb, as I have GPG signing on my
commits on by default (see git config commit.gpgsign), globally across
all my projects.

Is there an official stance on signed commits? I was thinking that
commit signing, at least for the maintainers that apply and push
patches, could be useful as a way to establish authenticity for every
commit that gets to the edk2 repos.

Best regards,

Pedro Falcato




Pedro Falcato
 

Hi James, Marvin,

Interesting points of view.
I still have a question though: If any part of the process got
compromised (maintainer, or in the worst case scenario, the repo
itself), is there anything that could be done
in order to assess the damage? I'd say signing could help establish
trust in a lot of those cases

Thanks,
Pedro

On Sun, Sep 12, 2021 at 10:53 AM Marvin Häuser <mhaeuser@posteo.de> wrote:

Hey,

Just my 2 cents...

Contributors: Git's stance is the author doesn't really matter as long
as the code is acceptable. For most people, you will not know them
anyway and it does not buy you much to know they own GitHub account XY.
If someone is impersonating a maintainer (who would push the changes
directly after review), that would be obvious anyway.

Maintainers: Why would someone have access to your SSH key but not your
GPG key? Especially if your commits are auto-signed, both keys are
likely equally readable. More factors do not meaningfully increase
security if they are not clearly separate.

I'm sure nobody minds your signatures though. :)

Best regards,
Marvin

On 11/09/2021 20:25, Pedro Falcato wrote:
Hi everyone,

Yesterday, when pushing my first commits to edk2-platforms (as the
Ext4Pkg maintainer), I noticed that my commits (see 7872c98 and
71f3343) stick out like a sore thumb, as I have GPG signing on my
commits on by default (see git config commit.gpgsign), globally across
all my projects.

Is there an official stance on signed commits? I was thinking that
commit signing, at least for the maintainers that apply and push
patches, could be useful as a way to establish authenticity for every
commit that gets to the edk2 repos.

Best regards,

Pedro Falcato




--
Pedro Falcato


Marvin Häuser
 

Hey Pedro,

Same point as before really, why would an attacker have access to your SSH key but not your GPG key? This scenario leaves out the possibly of an HTTPS over SSH attack, in which case as a security-aware person you use 2FA of course ( :) ), which means this is not possible without creating a personal access token. There is very little reason to do this at all - I never did this before, and I don't know anyone who does this with their private or work GitHub account (I think a few use it for CI?), at least that I know of. And even if you need one, and you give it push rights to actually push with, and you require GPG signatures globally, you again are keeping those two factors at least close together, if not in the same spot.

Best regards,
Marvin

On 13/09/2021 18:50, Pedro Falcato wrote:
Hi James, Marvin,

Interesting points of view.
I still have a question though: If any part of the process got
compromised (maintainer, or in the worst case scenario, the repo
itself), is there anything that could be done
in order to assess the damage? I'd say signing could help establish
trust in a lot of those cases

Thanks,
Pedro

On Sun, Sep 12, 2021 at 10:53 AM Marvin Häuser <mhaeuser@posteo.de> wrote:
Hey,

Just my 2 cents...

Contributors: Git's stance is the author doesn't really matter as long
as the code is acceptable. For most people, you will not know them
anyway and it does not buy you much to know they own GitHub account XY.
If someone is impersonating a maintainer (who would push the changes
directly after review), that would be obvious anyway.

Maintainers: Why would someone have access to your SSH key but not your
GPG key? Especially if your commits are auto-signed, both keys are
likely equally readable. More factors do not meaningfully increase
security if they are not clearly separate.

I'm sure nobody minds your signatures though. :)

Best regards,
Marvin

On 11/09/2021 20:25, Pedro Falcato wrote:
Hi everyone,

Yesterday, when pushing my first commits to edk2-platforms (as the
Ext4Pkg maintainer), I noticed that my commits (see 7872c98 and
71f3343) stick out like a sore thumb, as I have GPG signing on my
commits on by default (see git config commit.gpgsign), globally across
all my projects.

Is there an official stance on signed commits? I was thinking that
commit signing, at least for the maintainers that apply and push
patches, could be useful as a way to establish authenticity for every
commit that gets to the edk2 repos.

Best regards,

Pedro Falcato




James Bottomley
 

On Mon, 2021-09-13 at 19:31 +0000, Marvin Häuser wrote:
Hey Pedro,

Same point as before really, why would an attacker have access to
your SSH key but not your GPG key? This scenario leaves out the
possibly of an HTTPS over SSH attack, in which case as a security-
aware person you use 2FA of course ( :) ), which means this is not
possible without creating a personal access token. There is very
little reason to do this at all - I never did this before, and I
don't know anyone who does this with their private or work GitHub
account (I think a few use it for CI?), at least that I know of. And
even if you need one, and you give it push rights to actually push
with, and you require GPG signatures globally, you again are keeping
those two factors at least close together, if not in the same spot.
I think the scenario in question was someone hacking into github. They
can bypass your ssh login requirement without needing your key, because
that's enforced by github but they can't sign your commit unless they
compromise your laptop or token. There are many ways of hacking a
cloud service besides simply trying to fake the login or extract the
token from the user.

The way we get around this in Linux is with signed tags, but github
doesn't support that workflow.

I still really don't think signed commits adds much, even to github,
because to be informationally useful, all commits have to be signed.
Plus, anyway, if the entire site is compromised there'll be bigger
problems than checking commit signatures ...

James


Marvin Häuser
 

On 14/09/2021 20:02, James Bottomley wrote:
On Mon, 2021-09-13 at 19:31 +0000, Marvin Häuser wrote:
Hey Pedro,

Same point as before really, why would an attacker have access to
your SSH key but not your GPG key? This scenario leaves out the
possibly of an HTTPS over SSH attack, in which case as a security-
aware person you use 2FA of course ( :) ), which means this is not
possible without creating a personal access token. There is very
little reason to do this at all - I never did this before, and I
don't know anyone who does this with their private or work GitHub
account (I think a few use it for CI?), at least that I know of. And
even if you need one, and you give it push rights to actually push
with, and you require GPG signatures globally, you again are keeping
those two factors at least close together, if not in the same spot.
I think the scenario in question was someone hacking into github. They
can bypass your ssh login requirement without needing your key, because
that's enforced by github but they can't sign your commit unless they
compromise your laptop or token. There are many ways of hacking a
cloud service besides simply trying to fake the login or extract the
token from the user.
For the green "verified" tick it'd be sufficient to just enrol a new GPG key. There'd need to be some manual verification that it's always the same GPG key, which would require some trusted channel of transmission and updating it in case it is lost. To get literally anything out of this, a significant extra effort is required.

Best regards,
Marvin


The way we get around this in Linux is with signed tags, but github
doesn't support that workflow.

I still really don't think signed commits adds much, even to github,
because to be informationally useful, all commits have to be signed.
Plus, anyway, if the entire site is compromised there'll be bigger
problems than checking commit signatures ...

James