guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53901] [PATCH] publish: Sign only normative narinfo fields.


From: Ludovic Courtès
Subject: [bug#53901] [PATCH] publish: Sign only normative narinfo fields.
Date: Thu, 10 Feb 2022 22:09:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi,

pukkamustard <pukkamustard@posteo.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> This will allow mirror operators to alter the non-normative bits of a
>> narinfo, such as nar URLs and compression methods, without requiring
>> them to resign narinfos.
>>
>> [...]
>>
>> Thoughts?
>
> Sounds good to me.

Thanks.

> Maybe we can take the opportunity to do some cleanup?
>
> For example: We could get rid of the narinfo-contents field as we only
> sign the fixed normative fields (in a strict order). This would also
> allow us to remove the verify-everything-above-signature logic.

At this point, the client (narinfo consumer) cannot assume that the
server signs only the normative part, and only in a specific order; this
would be a protocol change (in fact, with this patch, ‘guix publish’
actually also signs the ‘Deriver’ field although that’s not a normative
field; maybe I should take ‘Deriver’ out.)

So I’m afraid we cannot clean that up yet.

> I recently tripped over the narinfo verification logic
> (https://issues.guix.gnu.org/52555#43) and think the changes you propose
> plus the simplifications above should make this security-critical code a
> bit easier to understand.

To be fair, the relevant bit is ‘narinfo-sha256’, which is 18 lines.

That said, in hindsight, you’re right: it would have been wiser to (1)
enforce a canonical representation of narinfos, and (2) require
signatures on a specific and ordered set of normative fields.

The problem is that all the narinfos out there fail #2 so we’ll
necessarily have to wait before we can really get rid of the
verify-everything-above-signature logic.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]