[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tricking peer review
From: |
Leo Famulari |
Subject: |
Re: Tricking peer review |
Date: |
Wed, 20 Oct 2021 19:09:09 -0400 |
On Fri, Oct 15, 2021 at 08:54:09PM +0200, Ludovic Courtès wrote:
> 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à:
[...]
> Thoughts?
It's a real risk... another illustration that our security model trusts
committers implicitly (not saying that's a bad thing or even avoidable).
In years past I mentioned a similar technique but based on using
old/vulnerable versions of security-critical packages like OpenSSL. The
same approach would have worked since we started using Nix's
content-addressed mirror.
> 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.
Nice feature! Sorry if this was already suggested, but is it possible to
create an argument to this variable that disallows use of the fallback
mechanisms? I would certainly use that while reviewing and testing my
own patches.
Re: Tricking peer review, Giovanni Biscuolo, 2021/10/20
patches for new packages proper workflow (Re: Tricking peer review), Giovanni Biscuolo, 2021/10/20
Re: Tricking peer review,
Leo Famulari <=
Re: Tricking peer review, Christine Lemmer-Webber, 2021/10/25