Use GnuPG in an automated environment?

[Daniel Kahn Gillmor]

On 04/08/2014 02:16 AM, Peter Michaux wrote:
> I'm concerned about the inability of reprepro to include in a single
> distribution two files which are only different versions of the same
> package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623

sorry for the off-topic aside, i'm glad to see that you've considered
reprepro.  I don't know what the use case is for multiple versions of
the same package in the same repo, but it does sound like if you need
that it's a compelling reason to manage to repo by hand for now.

> Also, I'd like to understand gpg better which is why I asked about the
> --default-key issue I noticed and didn't understand.

The key selection you're asking about is done by gpg in its best-effort
way.  Here's my understanding of its approach:

if you specify a key or a user ID, it first tries to find the primary
key associated with that specification (see "HOW TO SPECIFY A USER ID"
in gpg(1) ).  Then, when making a regular data signature (which is what
Release.gpg is), given that selected primary key, it checks to see if
there is a signing-capable subkey that has a newer creation time than
then primary key, and it uses that one.

If you want to specify a particular subkey or primary key as the signing
key, you should be able to do so by appending a "!" to the end of the
key ID:

  When using gpg an exclamation mark (!) may be appended to  force
  using  the specified primary or secondary key and not to try and
  calculate which primary or secondary key to use.

(note that the ! may need to be escaped to avoid your shell interpreting it)

If you can stand one more off-topic aside: I also recommend that for
important use cases like a software repository, you take care to
identify the signing key using a full fingerprint instead of a short
keyid.  short keyids are trivially spoofable, and if you ever update
your gnupg keyring from a public keyserver, it's possible for that
keyserver (or anyone in control of the network path between you and the
keyserver) to push an update into your keyring that matches the short
Key ID in question (even a secret key can be pushed in, i think).

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140408/2bb14670/attachment.sig>