From: Thiago Jung Bauermann <bauermann@kolabnow.com>
To: "Ludovic Courtès" <ludovic.courtes@inria.fr>,
"Liliana Marie Prikler" <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Tricking peer review
Date: Fri, 15 Oct 2021 20:13:36 -0300 [thread overview]
Message-ID: <2932876.amfyGXvyGV@popigai> (raw)
In-Reply-To: <daa70f61feb91fd0e358c110885ce4b2fc55bd61.camel@gmail.com>
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
next prev parent reply other threads:[~2021-10-15 23:14 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 18:54 Tricking peer review Ludovic Courtès
2021-10-15 22:03 ` Liliana Marie Prikler
2021-10-15 22:28 ` Ryan Prior
2021-10-15 22:45 ` Liliana Marie Prikler
2021-10-15 22:59 ` Ryan Prior
2021-10-18 7:40 ` Ludovic Courtès
2021-10-18 19:56 ` Ryan Prior
2021-10-19 8:39 ` zimoun
2021-10-20 23:03 ` Leo Famulari
2021-10-21 8:14 ` zimoun
2021-10-15 23:13 ` Thiago Jung Bauermann [this message]
2021-10-18 7:47 ` Ludovic Courtès
2021-10-18 7:34 ` Ludovic Courtès
2021-10-19 8:36 ` zimoun
2021-10-19 12:56 ` Ludovic Courtès
2021-10-19 14:22 ` zimoun
2021-10-19 15:41 ` Incentives for review Ludovic Courtès
2021-10-19 16:56 ` zimoun
2021-10-19 19:14 ` Ricardo Wurmus
2021-10-19 19:34 ` Christine Lemmer-Webber
2021-10-19 19:50 ` Joshua Branson
2021-10-21 20:03 ` Ludovic Courtès
2021-10-20 21:37 ` Thiago Jung Bauermann
2021-10-21 13:38 ` Artem Chernyak
2021-10-22 20:03 ` Thiago Jung Bauermann
2021-10-23 1:43 ` Kyle Meyer
2021-10-23 3:42 ` Thiago Jung Bauermann
2021-10-23 7:37 ` zimoun
2021-10-23 16:18 ` public-inbox/elfeed -> Maildir bridge (was: Incentives for review) Kyle Meyer
2021-10-24 12:18 ` Jonathan McHugh
2021-10-21 16:06 ` Incentives for review Ricardo Wurmus
2021-10-21 16:32 ` zimoun
2021-10-22 20:06 ` Thiago Jung Bauermann
2021-10-21 15:07 ` Katherine Cox-Buday
2021-10-21 16:10 ` Ricardo Wurmus
2021-10-21 17:52 ` Katherine Cox-Buday
2021-10-21 18:21 ` Arun Isaac
2021-10-21 19:58 ` Ludovic Courtès
2021-10-21 21:42 ` Ricardo Wurmus
2021-10-22 10:48 ` Arun Isaac
2021-10-22 11:21 ` zimoun
2021-10-23 6:09 ` Arun Isaac
2021-10-22 10:56 ` Jonathan McHugh
2021-10-22 7:40 ` zimoun
2021-10-22 11:09 ` Arun Isaac
2021-10-22 8:37 ` Jonathan McHugh
2021-10-22 9:15 ` zimoun
2021-10-22 10:40 ` Jonathan McHugh
2021-10-22 11:32 ` zimoun
2021-10-21 21:18 ` Jonathan McHugh
2021-10-22 10:44 ` Arun Isaac
2021-10-22 11:06 ` Jonathan McHugh
2021-10-21 21:22 ` zimoun
2021-10-28 14:57 ` Katherine Cox-Buday
2021-10-21 17:51 ` Vagrant Cascadian
2021-10-24 11:47 ` Efraim Flashner
2021-10-20 8:22 ` Tricking peer review Giovanni Biscuolo
2021-10-20 9:10 ` zimoun
2021-10-20 8:29 ` patches for new packages proper workflow (Re: Tricking peer review) Giovanni Biscuolo
2021-10-20 23:09 ` Tricking peer review Leo Famulari
2021-10-21 7:12 ` Ludovic Courtès
2021-10-25 13:09 ` Christine Lemmer-Webber
2021-10-28 8:38 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2932876.amfyGXvyGV@popigai \
--to=bauermann@kolabnow.com \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=ludovic.courtes@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).