Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Giovanni Biscuolo]

Hi Attila,

sorry for the delay in my reply,

I'm asking myself if this (sub)thread should be "condensed" in a
dedicated RFC (are RFCs official workflows in Guix, now?); if so, I
volunteer to file such an RFC in the next weeks.

Attila Lendvai <attila@lendvai.name> writes:

>> 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.

OK understood thanks!

[...]

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

I agree.

>> 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.

I agree, I was just brainstorming.

[...]

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature