From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Tricking peer review
Date: Mon, 18 Oct 2021 09:34:57 +0200 [thread overview]
Message-ID: <87o87mdc1d.fsf@inria.fr> (raw)
In-Reply-To: <daa70f61feb91fd0e358c110885ce4b2fc55bd61.camel@gmail.com> (Liliana Marie Prikler's message of "Sat, 16 Oct 2021 00:03:22 +0200")
Moin!
Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> Am Freitag, den 15.10.2021, 20:54 +0200 schrieb Ludovic Courtès:
[...]
>> 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.
At the time a package is committed, its source is normally not
downloaded from SWH—at least that’s what we aim for, and ‘guix lint’
warns against 404 source URLs. So when the package is reviewed and
committed, people can check the origin of the source, verify it against
published signatures when possible, and so on.
>> Also, just because a URL looks nice and is reachable doesn’t mean the
>> source is trustworthy either. An attacker could submit a package for
>> an obscure piece of software that happens to be malware. The
>> difference here is that the trick above would allow targeting a high-
>> impact package.
> Again, less of an issue w.r.t. review because the reviewers can at
> review time check that the tarball matches their expectations. I
> personally find "I can't find this source anywhere but on SWH" to be a
> perfect reason to reject software in the main Guix channel, though
> perhaps that rule is a bit softer in Guix Past.
Right. SWH is a fallback, meaning that, eventually, most source gets
downloaded from there (because the original hosting sites vanish); but
again, at the time of review, source must be available elsewhere.
>> On the plus side, such an attack would be recorded forever in Git
>> history.
> On the minus side, time-machine makes said record a landmine to step
> into.
That’s one way to look at it; the same could be said of unpatched
vulnerabilities found in old versions. It remains that deploying from a
pinned Guix revision has its uses.
[...]
> I agree, that cross-checking “guix download” might be good praxis for
> review.
Reviewing includes at least building the package, thus downloading its
source, and running running ‘guix lint’. So there’s nothing really new
here I guess,
> Perhaps in light of this we should extend it to Git/SVN/other VCS?
Thanks,
Ludo’.
next prev parent reply other threads:[~2021-10-18 7:35 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
2021-10-18 7:47 ` Ludovic Courtès
2021-10-18 7:34 ` Ludovic Courtès [this message]
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=87o87mdc1d.fsf@inria.fr \
--to=ludovic.courtes@inria.fr \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
/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).