Maxime Devos 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