GNU bug report logs - #57091
Git authentication reports subkey fingerprints

Previous Next

To reply to this bug, email your comments to 57091 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Git authentication reports subkey fingerprints
Date: Tue, 09 Aug 2022 23:07:19 +0200

Hello,

As Tobias explains at
<https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html> and
as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
git-authenticate) machinery reports the fingerprint of subkeys on
signatures (when subkeys are used) rather than the fingerprint of
primary keys.

This should be changed to report primary keys, at least optionally.

Ludo’.

Message #8 received at 57091 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>, 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Tue, 9 Aug 2022 23:20:01 +0200

[Message part 1 (text/plain, inline)]

On 09-08-2022 23:07, Ludovic Courtès wrote:
> Hello,
>
> As Tobias explains at
> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html>  and
> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
> git-authenticate) machinery reports the fingerprint of subkeys on
> signatures (when subkeys are used) rather than the fingerprint of
> primary keys.
>
> This should be changed to report primary keys, at least optionally.

Why should it be changed? IIUC .guix-authorizations and (guix ...) care 
about the key that things were signed with, not necessarily the primary 
key, so it seems to me that it needs to report the subkey fingerprint, 
not the fingerprint of the primary key it belongs to, as the primary key 
is irrelevant to them IIUC.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #11 received at 57091 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 12:24:23 +0200

Hi,

Maxime Devos <maximedevos <at> telenet.be> skribis:

> On 09-08-2022 23:07, Ludovic Courtès wrote:
>> Hello,
>>
>> As Tobias explains at
>> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html>  and
>> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
>> git-authenticate) machinery reports the fingerprint of subkeys on
>> signatures (when subkeys are used) rather than the fingerprint of
>> primary keys.
>>
>> This should be changed to report primary keys, at least optionally.
>
> Why should it be changed? IIUC .guix-authorizations and (guix ...)
> care about the key that things were signed with, not necessarily the
> primary key, so it seems to me that it needs to report the subkey
> fingerprint, not the fingerprint of the primary key it belongs to, as
> the primary key is irrelevant to them IIUC.

Yes, I kinda agree, but…  the motivation here is that OpenPGP user
interfaces don’t normally refer to subkey fingerprints; instead they
refer to primary key fingerprints, even if you use a subkey, which is
the point of subkeys AIUI.  That Guix treats subkeys differently is
confusing to seasoned OpenPGP users.

Ludo’.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Maxime Devos <maximedevos <at> telenet.be>
Cc: 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 11:17:39 +0000

This is not a mere UI issue.  Basic verification is currently broke^Wdifferent, too, or the latest incident wouldn't have happened.

Hmm.  I wonder...

Ludo', are you worried that, since we already handle revocations like GPG would, the 'proper' OpenPGPmodel could somehow break?  That we are in effect unable to safely fix this (yes, I maintain it is a) bug?

Apologies if I'm wildly off the mark here.  But then I'd like to hear some plausible threat models.  Maxime?

In their absence, nasty surprises like what happened last week are argument enough to (try to! :-) implement normal OpenPGP behaviour.



Kind regards,

T G-R

Sent on the go.  Excuse above-average rambliness.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Ludovic Courtès <ludo <at> gnu.org>,
 Maxime Devos <maximedevos <at> telenet.be>
Cc: 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 11:33:35 +0000

Of all the stupid typos...

>Ludo', are you worried that, since we already handle revocations like GPG would

...DON'T handle, of course, by design.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>, bug-guix <at> gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>
Cc: 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 17:07:12 +0200

[Message part 1 (text/plain, inline)]

On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:
> Apologies if I'm wildly off the mark here.  But then I'd like to hear some plausible threat models.  Maxime?

Here's a problem with allowing subkeys, if that's what you mean:

 * Expiration times and GPG-level revocation must be ignored (for
   time-travel, and pulling from an old Guix), similarly to why it must
   be ignored for when no subkeys are used
 * Someone used to GPG-style subkeys generates a new subkey to replace
   old expired subkey or revokes old subkey, without keeping in mind
   that Guix doesn't take that in account.
 * An attacker uses a compromised-but-revoked-or-expired subkey to
   compromise the channel.

Expiration times might be solvable by taking the commit time of the 
previous commit as 'current time' (not the commit that was signed, 
otherwise an attacker could just lie). I don't know a solution for 
GPG-level revocation of old subkeys but I haven't looked either.

Another problem:

 * When replacing the key in the 'keyring' branch with an 'updated' key
   that contains the new subkey, we have to be careful to never remove
   old subkeys, to avoid breaking time travel or pulling from old versions.

Greetings,
Maxime.

[Message part 2 (text/html, inline)]

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Ludovic Courtès <ludo <at> gnu.org>, bug-guix <at> gnu.org,
 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 18:31:41 +0200

Hi Maxime,

Quick reply mainly to say thanks for replying :-)

On 2022-08-11 17:07, Maxime Devos wrote:
> On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:
> 
>> Apologies if I'm wildly off the mark here.  But then I'd like to
>> hear some plausible threat models.  Maxime?
> 
> Here's a problem with allowing subkeys, if that's what you mean:

(Well, you snipped my previous paragraph where I mention what you seem 
to describe below, so yes.)

> 	* Expiration times and GPG-level revocation must be ignored (for
> time-travel, and pulling from an old Guix), similarly to why it must
> be ignored for when no subkeys are used
>  	* Someone used to GPG-style subkeys generates a new subkey to
> replace old expired subkey or revokes old subkey, without keeping in
> mind that Guix doesn't take that in account.
>  	* An attacker uses a compromised-but-revoked-or-expired subkey to
> compromise the channel.

Why does none of this apply to primary keys?

> Expiration times might be solvable by taking the commit time of the
> previous commit as 'current time' (not the commit that was signed,
> otherwise an attacker could just lie). I don't know a solution for
> GPG-level revocation of old subkeys but I haven't looked either.

Git commit dates aren't reliable.  Requiring that they be accurate going 
forward would be imposing yet another 'artificial'/idiosyncratic 
limitation.  I think we should be very hesitant to build a verification 
system on assumptions stacked just so.

> Another problem:
> 
>  	* When replacing the key in the 'keyring' branch with an 'updated'
> key that contains the new subkey, we have to be careful to never
> remove old subkeys, to avoid breaking time travel or pulling from old
> versions.

Sure.  We always need to be careful when updating the keyring branch.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Message #38 received at 57091 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: Ludovic Courtès <ludo <at> gnu.org>, bug-guix <at> gnu.org,
 57091 <at> debbugs.gnu.org
Subject: Re: bug#57091: Git authentication reports subkey fingerprints
Date: Thu, 11 Aug 2022 20:10:48 +0200

[Message part 1 (text/plain, inline)]

On 11-08-2022 18:31, Tobias Geerinckx-Rice wrote:
>>     * Expiration times and GPG-level revocation must be ignored (for
>> time-travel, and pulling from an old Guix), similarly to why it must
>> be ignored for when no subkeys are used
>>      * Someone used to GPG-style subkeys generates a new subkey to
>> replace old expired subkey or revokes old subkey, without keeping in
>> mind that Guix doesn't take that in account.
>>      * An attacker uses a compromised-but-revoked-or-expired subkey to
>> compromise the channel.
>
> Why does none of this apply to primary keys? 

For primary keys as they are currently used in Guix, to revoke a key 
(from Guix' point of view), you remove it from .guix-authorizations, done.

For revoking subkeys, you trust GPG or whatever to take care of things, 
but Guix-modified-to-allow-subkeys-too doesn't have a clue that the 
subkey should be considered revoked, se bullet list above.

That could be solved by also adding a list of revoked subkeys to 
.guix-authorization, but that seems opposite to the proposed change.

>> Expiration times might be solvable by taking the commit time of the
>> previous commit as 'current time' (not the commit that was signed,
>> otherwise an attacker could just lie). I don't know a solution for
>> GPG-level revocation of old subkeys but I haven't looked either.
>
> Git commit dates aren't reliable.  Requiring that they be accurate 
> going forward would be imposing yet another 'artificial'/idiosyncratic 
> limitation.  I think we should be very hesitant to build a 
> verification system on assumptions stacked just so.
Yes, forbidding setting the datetime to something way off (e.g. 
1970-01-01) for privacy or such is quite a limitation.

They do not have to be accurate however, as long as the discrepancies in 
commit dates / actual time (*) are small compared to the expiration times.

(*) of non-attackers -- assuming frequent commits, an attacker cannot 
trick the expiration mechanism into large time difference. That might 
not be good enough for branches like 'wip-foo' or channels with 
infrequent commits though.

Greetings,
Maxime.

[Message part 2 (text/html, inline)]

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.