Security pitfalls of .tar.asc

Konstantin Ryabitsev konstantin at
Fri Jul 6 23:57:15 CEST 2018

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

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


More information about the CGit mailing list