Hi, On Mon, Jul 31, 2017 at 04:57:22PM +0200, Maximiliano Curia wrote: > Hi, > > TL;DR We need to define a way to store detached upstream signatures in git. > I'm including a proposal, suggestions welcome. > > Not too long ago both uscan and dpkg-source added support for detached > upstream signatures, that is: a signed pgp signature for each upstream > released tarball. > > For this to be of any use, the source package needs to ship the keyring of > the upstream public keys (debian/upstream/signing-key.{asc,pgp}), with that > uscan can check the validity of the tarball. > > dpkg-source can also add the detached signatures in the corresponding > changes files and upload them as part of the source package, this way these > could be published in the archive and checked by our users. > > So far so good, but for packagers that work on git repositories to handle > their packages there is no defined way to handle/store these "extra" files. > > Using the usual git-buildpackage workflow (or equivalent git workflows) > maintainers prepare new upstream releases relying on pristine-tar so that > the released tarball can be generated from the git information. > > We need a similar mechanism to store the detached upstream signatures, a > simple approach could be to simply store the detached signatures in the > pristine-tar branch, and export these files when checking out the orig.tar. > This would mean to modify pristine-tar commit and checkout actions to take > into account the orig.tar.{$ext}.{asc,pgp} files.
We could also store it in the upstream tag message when importing the tarball but having it on pristine-tar looks nicer. Will you file wishlist bug against pristine-tar? Cheers, -- Guido > > Alternatively, we could use a different branch for these signatures, and > avoid meddling with pristine-tar, but this would add useless overhead. > > Happy hacking, > -- > "EIEIO Go home and have a glass of warm, dairy-fresh milk" > -- The GNU C Library Reference Manual, Chapter 2.2, Error Codes > Saludos /\/\ /\ >< `/