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

> 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

Best regards

Attachment: signature.asc
Description: PGP signature

Reply via email to