GNU bug report logs -
#57091
Git authentication reports subkey fingerprints
Previous Next
Full log
View this message in rfc822 format
[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)]
This bug report was last modified 2 years and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.