GNU bug report logs - #52555
[RFC PATCH 0/3] Decentralized substitute distribution with ERIS

Previous Next

Package: guix-patches;

Reported by: pukkamustard <pukkamustard <at> posteo.net>

Date: Thu, 16 Dec 2021 16:18:02 UTC

Severity: important

Tags: patch

Full log


Message #136 received at 52555 <at> debbugs.gnu.org (full text, mbox):

From: pukkamustard <pukkamustard <at> posteo.net>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: ~pukkamustard/eris <at> lists.sr.ht, 52555 <at> debbugs.gnu.org
Subject: Re: [bug#52555] [RFC PATCH v2 0/5] Decentralized substitute
 distribution with ERIS
Date: Fri, 04 Feb 2022 10:20:18 +0000
Maxime Devos <maximedevos <at> telenet.be> writes:

> pukkamustard schreef op wo 02-02-2022 om 11:10 [+0000]:
>> The ERIS URN is only used if the entire narinfo is signed with a
>> authorized signature.
>
> Perhaps I'm missing something here, but in that case, shouldn't "ERIS"
> be added to %mandatory-fields in (guix narinfo)?
>
> Anyway, I don't see what prevents an unauthorised narinfo with a ERIS
> URN to be used: the narinfo is chosen with
>
>   (define narinfo
>     (lookup-narinfo cache-urls store-item
>                     (if (%allow-unauthenticated-substitutes?)
>                         (const #t)
>                         (cut valid-narinfo? <> acl))))
>
> where lookup-narinfo is a tiny wrapper around lookup-narinfos/diverse.
> lookup-narinfos/diverse considers both unauthorised and authorised
> narinfos, and can choose an unauthorised narinfo if it's ‘equivalent’
> to an authorised narinfo (using equivalent-narinfo?)
>
> equivalent-narinfo? only looks at the hash, path, references and size,
> and ignores the ERIS.  As such, an unauthorised narinfo with a
> malicious ERIS URN could be selected.

You're right. I was not aware that parts of unauthorized narinfos are
used when they are deemed equavelent to authorized narinfos with
equivalent-narinfo?.

>
> However, it turns out that all this doesn't really matter: whether the
> port returned by 'fetch' in (guix scripts substitute) came from
> file://, http://, https:// or ERIS, the file hash is verified later
> anyway:
>
>                   ;; Compute the actual nar hash as we read it.
>                   ((algorithm expected)
>                    (narinfo-hash-algorithm+value narinfo))
>                   ((hashed get-hash)
>                    (open-hash-input-port algorithm input)))
>
>       [...]
>
>       ;; Check whether we got the data announced in NARINFO.
>       (let ((actual (get-hash)))
>         (if (bytevector=? actual expected)
>             [...]
>
> False alarm I guess!

Yeah, good that the hash is checked. Still, I think we should not even
try downloading a ERIS URN that is not authorized.

I think adding a check to equivalent-narinfo? that makes sure that the
ERIS URNs are equivalent if present would fix this. wdyt?

-pukkamustard




This bug report was last modified 1 year and 168 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.