Bug#882694: [sysadmin] Signatures on uncompressed archives
Control: tag -1 wontfix On Tue, 2018-03-13 at 13:47:10 -0400, Konstantin Ryabitsev wrote: > On 03/13/18 05:33, Uwe Kleine-König wrote: > >>> But it also has an impact on security: As long as the signature isn't > >>> verified I have to consider the .tar.xz "untrusted" and the less tools I > >>> have to make operate on it the better. This scheme allows an attacker > >>> that has control over a mirror to provide a .tar.xz that makes unxz do > >>> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an > >>> attack idea. > >> > >> Which is why we provide sha256sums.asc in each directory. > > > > That would be worth to point out more prominently on the above webpage > > then IMHO. > > We do, we have a whole section about sha256sums.asc files: > https://www.kernel.org/signature.html#kernel-org-checksum-autosigner-and-sha256sums-asc > > > When you recompress files you have to resign your sha256sum file, so I > > don't see the advantage "without needing to re-sign all files" you > > mentioned above. > > Released tarballs carry signatures from developers, not from any > automated infrastructure, so you can see how that complicates the > picture if we have to ask Linus or Greg KH to create new signatures for > all tarballs they've ever created. That's not incompatible with then generating signatures on the receiving side. In Debian we do distinguish between the developers preparing releases and signing the source and binary packages to upload to the Debian archive which then verifies those against the current allowed list of people, and whether their keys are not weak, or expired etc; and the archive then signing the metaindices that users download and verify against, so those can use certificates that can easily and are rotated continuously, can be expired, and resigned at any time, w/o bothering developers. This also means that the archive has to deploy and practice key rotation, which helps in case a disaster ensues. > > (Also recompressing has the immediate downside to break > > third-party tools that rely on unchanged files from upstream, which IMHO > > outweighs the disk space gained from recompressing.) > > I would say such tools are wrong because they expect non-normalized > formats to remain constant. I appreciate that I'm basically saying > "everyone is doing it wrong and we're the only ones who are shiny and > smell nice," but I do believe there's at least solid technical reasoning > behind our decision to sign .tar archives and not the compressed versions. I understand the apparent appeal of considering these artifacts as generated stuff. But IMO these are things that should be released and be considered immutable (like a crafted object), and not regenerated after the fact with something else, as mentioned in the thread that would break tons of expectations. > I think it will help you understand the reasoning more if I explain the > workflow behind how releases are currently produced (you can see my talk > about the entirety of the release process here: > https://www.youtube.com/watch?v=vohrz14S6JE): > > 1. Linus creates a .tar archive locally on his laptop, using "git > archive" -- which is always deterministic > 2. Linus creates a detached signature of that tar archive > 3. Linus sends us a very small request with just three things in it > >a. the tag >b. the prefix to use with "git archive" >c. the detached signature > > 4. We use these to create the .tar archive from our version of the tree, > verify it against Linus's detached signature, and if (and only if) the > signature verifies, we create .gz and .xz archives and upload them to > the frontends. > There are the following major benefits behind this process: > > 1. Linus only has to upload a few KB of data to produce a release, > instead of 200+ MB of combined .xz and .gz archive data. Since he > routinely produces releases while at conferences and remote diving > locations, he greatly appreciates not having to do that. > 2. More importantly, if Linus's laptop is compromised and someone tries > to sneak in a trojaned tarball between the time when "git archive" > finishes and "gpg --detach-sign" fires off, the signature verification > will fail when we try to generate the tarball on our end. Any trojans > would need to exist in the git tree, where they have a much greater > chance of being discovered than in a one-off tarball. By using our > current procedure we significantly reduce the risks of workstation > compromises resulting in trojaned tarballs carrying legitimate developer > signatures. Sure that makes sense from a developer to archive PoV, but… > It's true, we could ask Linus to generate signatures for the .xz archive > on his end, but this would require that he runs "xz -9" on a 600MB > tarball and wait half an hour for it to finish -- and then hope we > produce the same resulting .xz on our end, which is not at all > guaranteed between different xz versions, whereas git has tests that >
Processed: Re: Bug#882694: [sysadmin] Signatures on uncompressed archives
Processing control commands: > tag -1 wontfix Bug #882694 [dpkg-dev] dpkg-source: please add support for upstream signature on uncompressed tarball Added tag(s) wontfix. -- 882694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882694 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#882694: [sysadmin] Signatures on uncompressed archives
On 03/13/18 05:33, Uwe Kleine-König wrote: >>> But it also has an impact on security: As long as the signature isn't >>> verified I have to consider the .tar.xz "untrusted" and the less tools I >>> have to make operate on it the better. This scheme allows an attacker >>> that has control over a mirror to provide a .tar.xz that makes unxz do >>> undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an >>> attack idea. >> >> Which is why we provide sha256sums.asc in each directory. > > That would be worth to point out more prominently on the above webpage > then IMHO. We do, we have a whole section about sha256sums.asc files: https://www.kernel.org/signature.html#kernel-org-checksum-autosigner-and-sha256sums-asc > When you recompress files you have to resign your sha256sum file, so I > don't see the advantage "without needing to re-sign all files" you > mentioned above. Released tarballs carry signatures from developers, not from any automated infrastructure, so you can see how that complicates the picture if we have to ask Linus or Greg KH to create new signatures for all tarballs they've ever created. > (Also recompressing has the immediate downside to break > third-party tools that rely on unchanged files from upstream, which IMHO > outweighs the disk space gained from recompressing.) I would say such tools are wrong because they expect non-normalized formats to remain constant. I appreciate that I'm basically saying "everyone is doing it wrong and we're the only ones who are shiny and smell nice," but I do believe there's at least solid technical reasoning behind our decision to sign .tar archives and not the compressed versions. I think it will help you understand the reasoning more if I explain the workflow behind how releases are currently produced (you can see my talk about the entirety of the release process here: https://www.youtube.com/watch?v=vohrz14S6JE): 1. Linus creates a .tar archive locally on his laptop, using "git archive" -- which is always deterministic 2. Linus creates a detached signature of that tar archive 3. Linus sends us a very small request with just three things in it a. the tag b. the prefix to use with "git archive" c. the detached signature 4. We use these to create the .tar archive from our version of the tree, verify it against Linus's detached signature, and if (and only if) the signature verifies, we create .gz and .xz archives and upload them to the frontends. There are the following major benefits behind this process: 1. Linus only has to upload a few KB of data to produce a release, instead of 200+ MB of combined .xz and .gz archive data. Since he routinely produces releases while at conferences and remote diving locations, he greatly appreciates not having to do that. 2. More importantly, if Linus's laptop is compromised and someone tries to sneak in a trojaned tarball between the time when "git archive" finishes and "gpg --detach-sign" fires off, the signature verification will fail when we try to generate the tarball on our end. Any trojans would need to exist in the git tree, where they have a much greater chance of being discovered than in a one-off tarball. By using our current procedure we significantly reduce the risks of workstation compromises resulting in trojaned tarballs carrying legitimate developer signatures. It's true, we could ask Linus to generate signatures for the .xz archive on his end, but this would require that he runs "xz -9" on a 600MB tarball and wait half an hour for it to finish -- and then hope we produce the same resulting .xz on our end, which is not at all guaranteed between different xz versions, whereas git has tests that specifically check that git-archive generated .tar archives are identical between git releases. > Also for the attack vector against the decompressor, this effectively > renders the developer's signature useless because I have to trust the > sha256sum.asc (and so the archive key) before handing the compressed > file to the decompressor. > (Yeah I know, this is harder to exploit than introducing changes to the > tar archive, but IMHO this is no reason to keep this flaw unfixed.) I hope I've demonstrated how "fixing" this attack vector opens up a whole another one that is much, much worse. > Would it be possible to provide signatures on the compressed archives > using the same key that today signs sha256sums? I imagine this wouldn't > result in a significant retooling issue on your side and in return it > would simplify the handling of signature verification for all those who > care. No, because this would pretty much guarantee that people will not bother checking developer signatures and would just rely on automatically generated ones. This would violate our grand principle of "trust the developer, not infrastructure." I believe our approach has merit and results in better security protections. To verify the validity of any release you should: 1. Download the tarball and
Bug#882694: [sysadmin] Signatures on uncompressed archives
Hello Konstantin, On Mon, Mar 12, 2018 at 05:20:26PM -0400, Konstantin Ryabitsev wrote: > On 03/08/18 05:15, Uwe Kleine-König wrote: > > The kernel.org archive provides signatures for the software available > > (which is great!). The method to verify these according to > > > > > > https://www.kernel.org/category/signatures.html#using-gnupg-to-verify-kernel-signatures > > > > is to download the .tar.xz and the .tar.sign file, unxz the archive and > > check the signature against the .tar file. > > > > For one this is inconvenient because most tools don't know > > this scheme. In my case this is tooling from Debian to work with > > upstream archives[1]. > > I know it's a problem for Debian, I wouldn't call it a "problem". AFAICT Debian is well capable to adapt here and some tools already support this scheme of signing. My main focus is on the security implications, the inconvenience is just a side effect. > but changing this scheme for us would require significant retooling > just as it would for Debian infra. The major upside of the current > approach is that we are free to add new compressors, recompress > existing archives with higher compression ratios, etc, without needing > to re-sign all files. > > > But it also has an impact on security: As long as the signature isn't > > verified I have to consider the .tar.xz "untrusted" and the less tools I > > have to make operate on it the better. This scheme allows an attacker > > that has control over a mirror to provide a .tar.xz that makes unxz do > > undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an > > attack idea. > > Which is why we provide sha256sums.asc in each directory. That would be worth to point out more prominently on the above webpage then IMHO. When you recompress files you have to resign your sha256sum file, so I don't see the advantage "without needing to re-sign all files" you mentioned above. (Also recompressing has the immediate downside to break third-party tools that rely on unchanged files from upstream, which IMHO outweighs the disk space gained from recompressing.) Also for the attack vector against the decompressor, this effectively renders the developer's signature useless because I have to trust the sha256sum.asc (and so the archive key) before handing the compressed file to the decompressor. (Yeah I know, this is harder to exploit than introducing changes to the tar archive, but IMHO this is no reason to keep this flaw unfixed.) Would it be possible to provide signatures on the compressed archives using the same key that today signs sha256sums? I imagine this wouldn't result in a significant retooling issue on your side and in return it would simplify the handling of signature verification for all those who care. Best regards Uwe signature.asc Description: PGP signature
