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

["Marvin Häuser" <mhaeuser@posteo.de>]

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