* bug#57091: Git authentication reports subkey fingerprints @ 2022-08-09 21:07 Ludovic Courtès 2022-08-09 21:20 ` Maxime Devos 0 siblings, 1 reply; 8+ messages in thread From: Ludovic Courtès @ 2022-08-09 21:07 UTC (permalink / raw) To: 57091 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’. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-09 21:07 bug#57091: Git authentication reports subkey fingerprints Ludovic Courtès @ 2022-08-09 21:20 ` Maxime Devos 2022-08-11 10:24 ` Ludovic Courtès 0 siblings, 1 reply; 8+ messages in thread From: Maxime Devos @ 2022-08-09 21:20 UTC (permalink / raw) To: Ludovic Courtès, 57091 [-- Attachment #1.1.1: Type: text/plain, Size: 823 bytes --] 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. [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-09 21:20 ` Maxime Devos @ 2022-08-11 10:24 ` Ludovic Courtès 2022-08-11 11:17 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 0 siblings, 1 reply; 8+ messages in thread From: Ludovic Courtès @ 2022-08-11 10:24 UTC (permalink / raw) To: Maxime Devos; +Cc: 57091 Hi, Maxime Devos <maximedevos@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’. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-11 10:24 ` Ludovic Courtès @ 2022-08-11 11:17 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 11:33 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 15:07 ` Maxime Devos 0 siblings, 2 replies; 8+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 11:17 UTC (permalink / raw) To: 57091, ludo, maximedevos 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-11 11:17 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 11:33 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 15:07 ` Maxime Devos 1 sibling, 0 replies; 8+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 11:33 UTC (permalink / raw) To: 57091, ludo, maximedevos 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-11 11:17 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 11:33 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 15:07 ` Maxime Devos 2022-08-11 16:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 1 sibling, 1 reply; 8+ messages in thread From: Maxime Devos @ 2022-08-11 15:07 UTC (permalink / raw) To: me, 57091, ludo [-- Attachment #1.1.1.1: Type: text/plain, Size: 1257 bytes --] 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. [-- Attachment #1.1.1.2: Type: text/html, Size: 1842 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-11 15:07 ` Maxime Devos @ 2022-08-11 16:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 18:10 ` Maxime Devos 0 siblings, 1 reply; 8+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 16:31 UTC (permalink / raw) To: Maxime Devos; +Cc: ludo, 57091 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#57091: Git authentication reports subkey fingerprints 2022-08-11 16:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2022-08-11 18:10 ` Maxime Devos 0 siblings, 0 replies; 8+ messages in thread From: Maxime Devos @ 2022-08-11 18:10 UTC (permalink / raw) To: Tobias Geerinckx-Rice; +Cc: ludo, 57091 [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-08-11 18:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-09 21:07 bug#57091: Git authentication reports subkey fingerprints Ludovic Courtès 2022-08-09 21:20 ` Maxime Devos 2022-08-11 10:24 ` Ludovic Courtès 2022-08-11 11:17 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 11:33 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 15:07 ` Maxime Devos 2022-08-11 16:31 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2022-08-11 18:10 ` Maxime Devos
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).