Re: Tricking peer review

[Thiago Jung Bauermann]

Hello,

Em sexta-feira, 15 de outubro de 2021, às 19:03:22 -03, Liliana Marie 
Prikler escreveu:
> Am Freitag, den 15.10.2021, 20:54 +0200 schrieb Ludovic Courtès:
> > Consider this file as if it were a patch you’re reviewing:
> > 
> > (define-module (content-addressed))
> > (use-modules (guix)
> > 
> >              (guix build-system gnu)
> >              (guix licenses)
> >              (gnu packages perl))
> > 
> > (define-public sed
> > 
> >   (package
> >   
> >    (name "sed")
> >    (version "4.8")
> >    (source (origin
> >    
> >             (method url-fetch)
> >             (uri (string-append "mirror://gnu/zed/sed-" version
> >             
> >                                 ".tar.gz"))
> 
> To be fair, gnu/zed sounds wonky, but you could try inserting a version
> that does not exist (e.g. 1+ the current latest version) and as a
> committer thereby bypass review entirely.  However, given that we trust
> committers in this aspect, I'd say they should be able to verify both
> URI and version field.  This is trivially possible with most schemes
> safe for the mirror:// one.
> 
> >             (sha256
> >             
> >              (base32
> >              
> >               "1yy33kiwrxrwj2nxa4fg15bvmwyghqbs8qwkdvy5phm784f7brjq")
> > 
> > )))
> > 
> >    (build-system gnu-build-system)
> >    (synopsis "Stream editor")
> >    (native-inputs
> >    
> >     `(("perl" ,perl)))                            ;for tests
> >    
> >    (description
> >    
> >     "Sed is a non-interactive, text stream editor.  It receives a
> > 
> > text
> > input from a file or from standard input and it then applies a series
> > of text
> > editing commands to the stream and prints its output to standard
> > output.  It
> > is often used for substituting text patterns in a stream.  The GNU
> > implementation offers several extensions over the standard utility.")
> > 
> >    (license gpl3+)
> >    (home-page "https://www.gnu.org/software/sed/";)))
> > 
> > sed
> > 
> > It builds just fine:
> > 
> > --8<---------------cut here---------------start------------->8---
> > $ guix build -f /tmp/content-addressed.scm
> > /gnu/store/lpais26sjwxcyl7y7jqns6f5qrbrnb34-sed-4.8
> > $ guix build -f /tmp/content-addressed.scm -S --check -v0
> > /gnu/store/mgais6lk92mm8n5kyx70knr11jbwgfhr-sed-4.8.tar.gz
> > --8<---------------cut here---------------end--------------->8---
> > 
> > Did you spot a problem?
> > 
> > …
> > 
> > 
> > So, what did we just build?
> > 
> > --8<---------------cut here---------------start------------->8---
> > $ ls $(guix build -f /tmp/content-addressed.scm)/bin
> > egrep  fgrep  grep
> > --8<---------------cut here---------------end--------------->8---
> > 
> > Oh oh!  This ‘sed’ package is giving us ‘grep’!  How come?
> > 
> > The trick is easy: we give a URL that’s actually 404, with the hash
> > of a file that can be found on Software Heritage (in this case, that
> > of ‘grep-3.4.tar.xz’).  When downloading the source, the automatic
> > content-addressed fallback kicks in, and voilà:
> > 
> > --8<---------------cut here---------------start------------->8---
> > $ guix build -f /tmp/content-addressed.scm  -S --check
> > 
> > La jena derivaĵo estos konstruata:
> >    /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv
> > 
> > building /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-
> > 4.8.tar.gz.drv...
> > 
> > Starting download of /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-
> > 4.8.tar.gz
> > 
> > > From https://ftpmirror.gnu.org/gnu/zed/sed-4.8.tar.gz...
> > 
> > following redirection to `
> > https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz'...
> > download failed "https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz";
> > 404 "Not Found"
> > 
> > [...]
> > 
> > Starting download of /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-
> > 4.8.tar.gz
> > 
> > > From
> > > https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a
> > > 7c25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/ ...
> > 
> > downloading from
> > https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a7c
> > 25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/ ...
> > 
> > warning: rewriting hashes in
> > `/gnu/store/mgais6lk92mm8n5kyx70knr11jbwgfhr-sed-4.8.tar.gz'; cross
> > fingers
> > successfully built /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-
> > 4.8.tar.gz.drv
> > --8<---------------cut here---------------end--------------->8---
> > 
> > It’s nothing new, it’s what I do when I want to test the download
> > fallbacks (see also ‘GUIX_DOWNLOAD_FALLBACK_TEST’ in commit
> > c4a7aa82e25503133a1bd33148d17968c899a5f5).  Still, I wonder if it
> > could somehow be abused to have malicious packages pass review.
> 
> I don't think this is much of a problem for packages where we have
> another source of truth (in this case mirrors/archives of sed), but it
> does point at a bigger problem when SWH is our only source of truth.
> I.e. when trying to conserve such software for the future, when other
> archives might fail and perhaps SHA256 itself might be broken, we can
> no longer be sure that the Guix time-machine indeed does what it
> promises.

I’ve been thinking lately that Guix {sh,c}ould have a new ’release-signing-
keys’ field in the package record which would list the keys that are known 
to sign official releases of the package. Then Guix would check the tarball/
git commit/git tag when downloading it. It would be an additional (and IMHO 
important) source of truth.

There are details that would need to be hashed out such as how to deal with 
revoked keys or whether to store the keys themselves on the Guix repo or 
anywhere else in Guix’s infrastructure, but I think it’s possible to arrive 
at a reasonable solution.

Not all projects sign their release artifacts, but some do and it would be 
nice to take advantage of that.

-- 
Thanks,
Thiago