Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Daniel Kahn Gillmor]

On Wed 2017-09-20 01:47:00 +0200, Tomasz Buchert wrote:
> So let's assume that git-archive can produce a reproducible,
> uncompressed tarball, given a particular githash. Why not ask
> interested upstream developers to do something like that:
>
>   git tag -s TAGNAME -m "$(git archive --format tar HEAD | sha512sum)"
>
> The tag proves:
>   (1) the history in the git repository, as always
>   (2) but also that a tar generated from this tag should have a particular sha512 hash

i'm reluctant to have the tag message be a bare sha512 hash (that could
mean just about anything!), but i do like the basic idea.  maybe it
needs a bit more cryptographic structure, though.

What about just encouraging developers to store a signature for the
uncompressed tarball as a git note with:

    git archive --format tar $TAGNAME | gpg --armor --detach-sign | git notes add -F - $TAGNAME

This is conveniently verified with:

    gpg --verify <(git notes show $TAGNAME) <(git archive --format tar $TAGNAME)

I'm not sure how well notes transport across multiple git repos, though,
i haven't tried.


Or, stuff the signature itself in the git tag message while making the
tag in the first place:

    (echo "Tagging $PROJECTNAME $TAGNAME" && \
      git archive --format tar "$COMMIT" | gpg --armor --detach-sign ) | \
      git tag "$TAGNAME" "$COMMIT"

Though i'm not actually sure how to verify that one unless you *also*
sign the tag itself, which starts to get pretty meta.  Any suggestions?

or, maybe there's something that could be added to a tag, like an
"archive signature" property?  or just a second signature that lives
after the first one?  I'm not exactly sure how to do that.

> But it should be totally fine at least for "release tags". The cool
> thing is that it could be upstreamed in git, as a flag to git-tag, or
> at least provided as an extension, such as git-atag (aka
> git-archive-tag, you get the idea).

Yes, i like this idea.  If there were One Standard Way™ to do it, and it
was just an additional flag to ask people to add to their "git tag"
commands, then it would make it really easy to pull "upstream tarball
signatures" out of projects that don't release tarballs any more, just
git repositories.  For folks using gpg-agent in its standard
configuration, it shouldn't cause them any extra hassle either, since
the passphrase for the first signature will be cached and re-used for
the subsequent signature.

Who would you talk to about getting something like that included into
git upstream?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20170922/38c542a6/attachment.sig>