[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’.