From mboxrd@z Thu Jan 1 00:00:00 1970 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 6 Jul 2018 17:57:15 -0400 Subject: Security pitfalls of .tar.asc In-Reply-To: References: Message-ID: <20180706215715.GC21428@puremoods> 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