New supply-chain security tool: backseat-signed

kpcyrd kpcyrd at archlinux.org
Thu Apr 4 23:30:51 UTC 2024


On 4/5/24 12:31 AM, Adrian Bunk wrote:
> Hashes of "git archive" tarballs are anyway not stable,
> so whatever a maintainer generates is not worse than what is on Github.
> 
> Any proper tooling would have to verify that the contents is equal.
> 
>> ...
>> Being able to disregard the compression layer is still necessary however,
>> because Debian (as far as I know) never takes the hash of the inner .tar
>> file but only the compressed one. Because of this you may still need to
>> provide `--orig <path>` if you want to compare with an uncompressed tar.
>> ...
> 
> Right now the preferred form of source in Debian is an upstream-signed
> release tarball, NOT anything from git.
> 
> An actual improvement would be to automatically and 100% reliably
> verify that a given tarball matches the commit ID and signed git tag
> in an upstream git tree.

I strongly disagree. I think the upstream signature is overrated.

It's from the old mindset of code signing being the only way of securely 
getting code from upstream. Recent events have shown (instead of 
bothering upstream for signatures) it's much more important to have 
clarity and transparency what's in the code that is compiled into 
binaries and executed on our computers, instead of who we got it from. 
The entire reproducible builds effort is based on the idea of the source 
code in Debian being safe and sound to use.

If upstream refused to sign anything but pre-compiled llvm IR, I'd put 
both the IR and signature in the trash and build from source code.

If upstream wouldn't sign anything but autotools pre-processed archives 
with 25k lines of auto-generated shell scripts I'd put it next to the IR 
and build from the actual source code as well.

If upstream would only sign a tarball with files sorted in the order 
they were returned by their kernel to readdir(), I'd raise the question 
why we're having this in 2024 (and possibly suggest to use a tar with 
sorted entries).

Although to be honest if this would really be the only problem we'd be 
having, I'd likely not care anymore and put my time to better use.

> Or perhaps stop using tarballs in Debian as sole permitted
> form of source.

I'd be fine with that.

cheers,
kpcyrd


More information about the rb-general mailing list