[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upstream Tarball Signature Files



On Fri 2017-08-18 12:08:02 +0200, Guillem Jover wrote:
> Hmmm, I've been thinking about this a bit, and perhaps it would be
> better if dpkg-source auto-converted any .sig binary signature into
> an .asc ASCII armored one when generating the source package (as long
> as there is no pre-existing .asc file). This has the advantage of not
> requiring devscripts to be installed, preserves compatibility with
> stable dpkg-source and DAK so it can be used right away, and allows
> us to keep using a single signature format. I've got code doing that
> now, which I can merged for 1.19.0, I guess the only possibly
> contentious point is that this might seem like doing too much magic
> from within dpkg-source?
>
> If people are comfortable with this, I'm happy to merge it.

I've got no objection to this.

I confess that i've been taking the boring/silly/cheating way out and if
upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
even converting its contents to ASCII-armored form) and the rest of the
toolchain seems to just happily accept it -- it'd be even nicer if dpkg
and/or uscan was to normalize the contents to match the file extension.

Note that it's possible that something named .sig is itself already
armored, though, we don't want to double-armor it.

Lastly, it's conceivable that we might want to take an already-armored
.asc, and "launder" the armor, to stabilize it (e.g. stripping
non-cryptographically-relevant comments, other weird OpenPGP packets,
etc, which could all be stuffed into the detached signature).  I am not
proposing this as a requirement, and i don't want the suggestion to
block the .sig→.asc fix, but if thinking about that part of the code, it
might be easy to do at the time.  Doing so would reduce the amount of
non-cryptographically-justified sidechannels that debian is willing to
cart around on behalf of upstream authors.  (of course, we're currently
willing to cart stuff around for upstream authors who don't make
cryptographic signatures at all today, so maybe it's too nit-picky to
obsess about sidechannels just for those who make signatures)

Thanks for working on this, Guillem!

     --dkg

Attachment: signature.asc
Description: PGP signature


Reply to: