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]

Hi Guillem--

On Thu 2017-08-17 01:05:46 +0200, Guillem Jover wrote:
> It seems to me like you are perhaps trying to reimplement dpkg source
> format «3.0 (git)» (described in man dpkg-source)? :)

Thanks for that pointer, it does seem similar.

I was hoping that we could produce an actual orig.tar.gz (so that the
rest of the tools could use it as they have traditionally) and then some
extra thing outside of the orig.tar.gz that, combined with the tarball,
could be used to recreate the .git/ repository well enough to be able to
(a) recreate the tarball, and (b) cryptographically verify the tag.

this would solve my use case (being able to record and ship upstream's
cryptographic signatures, when upstream "releases" with signed tags)
without requiring the rest of the debian infrastructure to cope with git
bundles as "orig.tar.gz-equivalent" blobs.

But if there's a plan for "3.0 (git)" to become acceptable in debian,
then it does seem like that might be the simplest way to move forward.

i'll play around with git-bundle to try to understand it better.  from a
scan of dpkg-source(1) and the various git manpages that i'm used to
reading, i don't understand what .gitshallow or .git/shallow are
supposed to do.  Does it get shipped alongside the .git?  does
.git/shallow have meaning for other tools that i should be aware of?

         --dkg