* Security pitfalls of .tar.asc
@ 2018-07-05 0:54 Jason
2018-07-05 6:58 ` list
2018-07-06 21:57 ` konstantin
0 siblings, 2 replies; 3+ messages in thread
From: Jason @ 2018-07-05 0:54 UTC (permalink / raw)
Hi list,
The upcoming cgit 1.2 release will have support for attaching .asc
signatures to tarballs. Adding a .tar.xz.asc is straightforward and
works as expected. But there's also display logic for showing .tar.asc
signatures next to .tar.xz files. The intent is to do something like
this:
$ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86268 0 86268 0 0 122k 0 --:--:-- --:--:-- --:--:-- 123k
$ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.asc
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 858 0 858 0 0 2150 0 --:--:-- --:--:-- --:--:-- 2177
$ unxz cgit-1.1.tar.xz
$ gpg --verify cgit-1.1.tar.asc
gpg: assuming signed data in 'cgit-1.1.tar'
gpg: Signature made Thu 05 Jul 2018 02:34:20 AM CEST
gpg: using RSA key AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
gpg: issuer "jason at zx2c4.com"
gpg: Good signature from "Jason A. Donenfeld <Jason at zx2c4.com>" [ultimate]
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?
Regards,
Jason
^ permalink raw reply [flat|nested] 3+ messages in thread
* Security pitfalls of .tar.asc
2018-07-05 0:54 Security pitfalls of .tar.asc Jason
@ 2018-07-05 6:58 ` list
2018-07-06 21:57 ` konstantin
1 sibling, 0 replies; 3+ messages in thread
From: list @ 2018-07-05 6:58 UTC (permalink / raw)
"Jason A. Donenfeld" <Jason at zx2c4.com> on Thu, 2018/07/05 02:54:
> Hi list,
>
> The upcoming cgit 1.2 release will have support for attaching .asc
> signatures to tarballs. Adding a .tar.xz.asc is straightforward and
> works as expected. But there's also display logic for showing .tar.asc
> signatures next to .tar.xz files. The intent is to do something like
> this:
>
> $ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.xz
> % Total % Received % Xferd Average Speed Time Time Time
> Current Dload Upload Total Spent Left Speed
> 100 86268 0 86268 0 0 122k 0 --:--:-- --:--:-- --:--:--
> 123k $ curl -LO https://git.zx2c4.com/cgit/snapshot/cgit-1.1.tar.asc
> % Total % Received % Xferd Average Speed Time Time Time
> Current Dload Upload Total Spent Left Speed
> 100 858 0 858 0 0 2150 0 --:--:-- --:--:-- --:--:--
> 2177 $ unxz cgit-1.1.tar.xz
> $ gpg --verify cgit-1.1.tar.asc
> gpg: assuming signed data in 'cgit-1.1.tar'
> gpg: Signature made Thu 05 Jul 2018 02:34:20 AM CEST
> gpg: using RSA key AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
> gpg: issuer "jason at zx2c4.com"
> gpg: Good signature from "Jason A. Donenfeld <Jason at zx2c4.com>" [ultimate]
>
> 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?
Well, providing signatures for the uncompressed tar is common practice for
different projects, linux [0] and e2fsprogs [1] just being two of them.
This was requested from Konstantin Ryabitsev to be used on kernel.org.
As nobody is forced to use this I am fine this way. Note that providing a
signature for .tar.{gz,bz2,xz} makes the download link for .tar.asc disappear
even if the signature is available.
[0] https://cdn.kernel.org/pub/linux/kernel/v4.x/
[1]
https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.44.2/
--
main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];)
putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20180705/78ee37aa/attachment.asc>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Security pitfalls of .tar.asc
2018-07-05 0:54 Security pitfalls of .tar.asc Jason
2018-07-05 6:58 ` list
@ 2018-07-06 21:57 ` konstantin
1 sibling, 0 replies; 3+ messages in thread
From: konstantin @ 2018-07-06 21:57 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-07-06 21:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-05 0:54 Security pitfalls of .tar.asc Jason
2018-07-05 6:58 ` list
2018-07-06 21:57 ` konstantin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).