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

Re: debian/upstream/signing-key.asc in policy 4.1.0

Osamu Aoki <osamu@debian.org> writes:

> After all the discussion, Policy 4.1.0 goes as:

> | 4.11. Optional upstream source location: debian/watch¶
> | 
> | This is an optional, recommended configuration file for the uscan
> | utility which defines how to automatically scan ftp or http sites for
> | newly available updates of the package. This is also used by some Debian
> | QA tools to help with quality control and maintenance of the
> | distribution as a whole.
> | 
> | If the upstream maintainer of the software provides OpenPGP signatures
> | for new releases, including the information required for uscan to verify
> | signatures for new upstream releases is also recommended. To do this,
> | use the pgpsigurlmangle option in debian/watch to specify the location
> | of the upstream signature, and include the key or keys used to sign
> | upstream releases in the Debian source package as
> | debian/upstream/signing-key.asc.
> | 
> | For more information about uscan and these options, including how to
> | generate the file containing upstream signing keys, see uscan.

> Please note few things which I failed to share:

> The current uscan supports both 
>  debian/upstream/signing-key.asc
>  debian/upstream/signing-key.pgp

> Now, if debian/upstream/signing-key.asc is used, uscan converts it to
> <tmpdir>/signing-key.gpg by gpg for use with gpgv to check signature.
> (I think the same goes with dpkg-source).  It looks extra CPU power
> waste but not a big deal. I do this conversion since no documentation
> mention keyring can be ascii armored for gpgv.

> The updated uscan will support debian/upstream/signing-key.asc only and
> internally convert it <tmpdir>/signing-key.gpg.  I will make uscan to
> convert other formats to this policy compliant *.asc.  Also make noise
> to the maintainer to push them to policy 4.1.0

Note that this Policy language is carefully written to make it perfectly
fine for uscan to support all the things it currently supports, since it
only talks about what Policy recommends the maintainer does.  So don't
feel any obligation to change what uscan is doing on Policy's account

That said, as discussed elsewhere, I'm a huge fan of there being only one
way to do something like this, with some easy tools to convert other
methods into that one method.  It reduces everyone's cognitive load in the

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: