Security pitfalls of .tar.asc

[konstantin at linuxfoundation.org (Konstantin Ryabitsev)]

On Thu, Jul 05, 2018 at 02:54:52AM +0200, Jason A. Donenfeld wrote:
> This works fine, but there's something a bit troubling about it: it
> means that users are instructed to run untrusted tarballs through
> `unxz`, which is big and complicated and could have nasty
> vulnerabilities. My understanding is that this is desired because
> .tar.xz is not stable -- xz might do different things between versions
> or compression levels -- whereas git considers its .tar output to be a
> stable format. So I can see why it'd be desirable to host .tar.asc
> instead of .tar.xz.asc. But from a security perspective, this might be
> sub-optimal.
> 
> Thoughts?

I've had the same discussion with Debian folks a little while back,
which I won't rehash here -- see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882694#25

Worrying about vulnerabilities in unxz is valid, but xz is merely the
last tool in a whole chain of software a person would need to use to get
the tarball and the signature file to where they could run unxz and
gpg --verify. We'd also need to worry about curl/wget/firefox, the tcp
stack, the "ls" and "cp" commands, etc etc.

On the kernel.org side of things we offer sha256sums.asc file in each
directory specifically as a way to quickly verify file integrity before
running unxz (but you still have to download that file, so the caution
about wget/curl/firefox/etc/etc remains :)).

-K