Re: [PATCH] build: sign tarball instead of sha256sum

[Adam Majer <amajer@suse.de>]

On 2019-03-14 11:51 p.m., Daniel Kahn Gillmor wrote:
> Sorry to only be getting to this now.  I think the original mechanism,
> despite being non-standard, is actually a more robust approach, so i
> recommend reverting this change.
> 
> A detached signature on object X does *not* cover the name of object X.
> 
> So for some existing version Y of notmuch, if an attacker takes
> notmuch-Y.tgz and notmuch-Y.tgz.asc and renames them both to
> notmuch-Z.tgz and notmuch-Z.tgz.asc, they can make it look like a new
> version (version Z) of notmuch is available!

All other software I've encountered, the tarball is signed. This semantic allows for automated
checks by our Open Build Server instance to make sure there is no file system corruption or other
modification. If something else is signed, like the sha256, then only that small file is checked. In
this case, adding explicit checks would add an extra BuildRequires in the build process to pull in
gpg, which is excessive.

Instead of reverting, how about distributing the .asc file and an inline signed checksum file? Then
you have both signed. Just sign the .sha256 inline and sha256 will verify and at least it will not
look like a detached signature. And `sha256 -c` on signed file directly also will work.

sha256sum notmuch-0.28.3.tar.gz | gpg --clearsign -a - > notmuch-0.28.3.tar.gz.sha256
gpg -b -a notmuch-0.28.3.tar.gz

And then you have signed sha256 for people that want to check that. And you have a detached
signature, for people that want to use that. And need to have funny looking unsigned intermediaries
and detached looking signatures that really aren't.

- Adam