Question about EDK2 and commit signing

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

Re: [edk2-devel] Question about EDK2 and commit signing

[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

Re: [edk2-devel] Question about EDK2 and commit signing

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

Re: [edk2-devel] Question about EDK2 and commit signing

[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

Re: [edk2-devel] Question about EDK2 and commit signing

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

Re: [edk2-devel] Question about EDK2 and commit signing

[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

Re: [edk2-devel] Question about EDK2 and commit signing

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