Re: Detached upstream signature and git packaging

2017-08-11 Thread Tomasz Buchert
On 02/08/17 21:54, Guido Günther wrote:
>
> [...]
>
> 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

For those interested, the bug is https://bugs.debian.org/871809.

Tomasz


signature.asc
Description: PGP signature


Re: Detached upstream signature and git packaging

2017-08-02 Thread Guido Günther
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,
> -- 
> "EIEIOGo home and have a glass of warm, dairy-fresh milk"
> -- The GNU C Library Reference Manual, Chapter 2.2, Error Codes
> Saludos /\/\ /\ >< `/




Detached upstream signature and git packaging

2017-07-31 Thread Maximiliano Curia

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.


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 /\/\ /\ >< `/


signature.asc
Description: PGP signature