[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)
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), (continued)
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Skyler Ferris, 2024/04/13
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Ludovic Courtès, 2024/04/19
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Attila Lendvai, 2024/04/12
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Ludovic Courtès, 2024/04/12
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Giovanni Biscuolo, 2024/04/13
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Giovanni Biscuolo, 2024/04/05
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils),
Attila Lendvai <=
- Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Giovanni Biscuolo, 2024/04/13
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Ricardo Wurmus, 2024/04/04
Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils), Jan Wielkiewicz, 2024/04/05