bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2189 bytes --]


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.

[-- Attachment #1.1.1.2: Type: text/html, Size: 3278 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]