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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch