On Tue 2019-03-12 07:55:19 -0300, David Bremner wrote:
> David Bremner <david@tethera.net> writes:
>
>> Adam Majer pointed out in [1] the way were signing releases was
>> unusual. Neither Carl nor I could think of a good reason for
>> explicitely signing the checksum (internally of course that's what GPG
>> is going anyway).
>
> It seemed unlikely that there would be much testing for this (but feel
> free!), so I have pushed it. I can fix any glitches during the next
> release.

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!  The only way to detect the
attack is to store a log of timestamps of previous releases, and try to
compare timestamps (though this itself can be confusing and wrong if we
were to maintain multiple branches concurrently).  This permits a
"rollback" or "version freeze" attack, which we probably don't want to
encourage.

However, if the thing verified is the output of sha256sum, then the
*filename* of the tarball itself is included, then the standard
verification step will is sufficient to ensure that you've got the right
version in the filename.

In bash, verifying version 0.28.3 would look something like:

    set -o pipefail
    set -x
    wget https://notmuchmail.org/releases/notmuch-0.28.3.tar.gz{,.sha256.asc}
    gpgv --keyring ./notmuch-signers.pgp  --output - notmuch-0.28.3.tar.gz.sha256.asc | sha256sum -c -

This is resistant to any attacker who manages to place or rename files
on https://notmuchmail.org/releases/.

That's why I support reversion here.  Apologies for the delay in
encountering this thread.

Regards,

   --dkg