guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: backdoor injection via release tarballs combined with binary artifac


From: Attila Lendvai
Subject: Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)
Date: Fri, 05 Apr 2024 14:51:33 +0000

> Are there other issues (different from the "host cannot execute target
> binary") that makes relesase tarballs indispensable for some upstream
> projects?


i didn't mean to say that tarballs are indispensible. i just wanted to point 
out that it's not as simple as going through each package definition and 
robotically changing the source origin from tarball to git repo. it costs some 
effort, but i don't mean to suggest that it's not worth doing.


> So, while "almost all the world" is applying wrong solutions to the
> source tarball reproducibility problem, what can Guix do?


AFAIU the plan is straightforward: change all package definitions to point to 
the (git) repos of the upstream, and ignore any generated ./configure scripts 
if it happens to be checked into the repo.

it involves quite some work, both in quantity, and also some thinking around 
surprises.

i think a good first step would be to reword the packaging guidelines in the 
doc to strongly prefer VCS sources instead of tarballs.


> Even if We™ (ehrm) find a solution to the source tarball reproducibility
> problem (potentially allowing us to patch all the upstream makefiles
> with specific phases in our packages definitions) are we really going to
> start our own (or one managed by the reproducible build community)
> "reproducible source tarballs" repository? Is this feaseable?


but why would that be any better than simply building from git? which, i think, 
would even take less effort.


> > but these generated man files are part of the release tarball, so
> > cross compilation works fine using the tarball.
> 
> 
> AFAIU in this case there is an easy alternative: distribute the
> (generated) man files as code tracked in the DVCS (e.g. git) repo
> itself.


yes, that would work in this case (although, that man page is guaranteed to go 
stale). my proposal was to simply drop the generated man file. it adds very 
little value (although it's not zero; web search, etc).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is easy to be conspicuously 'compassionate' if others are being forced to 
pay the cost.”
        — Murray N. Rothbard (1926–1995)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]