[pkg-gnupg-maint] Debian gnupg2 (2.1.11-7+exp1) experimental

[Daniel Kahn Gillmor]

On Fri 2016-04-22 09:18:59 -0400, Julian Andres Klode wrote:
> IIRC, APT needs to merge keyrings die to gpg's number of keyrings
> limit

hang on -- this kind of begs the question: we need gpg because we need
to merge keyrings for gpg? :)

I think you're saying that we need to merge keyrings because of gpgv's
limit of 40 keyrings, is that right?

i suppose i can imagine some vaguely sane system that wants 40 keyrings
-- maybe the system pulls packages from 10 repos, and each repo has 4
different keys, and they're all placed separately.  What kind of limit
would you prefer?

As an aside: why is there a limit anyway?

g10/keydb.c contains:

#define MAX_KEYDB_RESOURCES 40

which is used to define a static array of keyrings; each instantiated
keyring itself apparently includes a comparably-sized static array, so
the size of RAM consumed grows with the square of the number of keyrings
used.  I confess i don't understand this arrangement; perhaps it could
be refactored upstream eventually to remove the hard limit.  Werner, can
you explain the situation here?

In the meantime, I'd be happy to boost this to a reasonable number
(something that would satisfy the apt team) in the debian packaging even
if upstream decides to keep it at 40.  what do y'all think is "a
reasonable number" ?

(even further aside: for gpgv, the list of keyrings should be much
simpler to maintain than for gpg, since gpgv is never expected to modify
any of the keyrings; the real complications here for gpgv lie in the
reuse of the code between gpg and gpgv; if it were possible to have a
separate codepath for keyring loading for gpgv, i think it would be much
simpler)

Finally, if merging is still necessary for other reasons, you should be
able to use /bin/cat to merge binary-format transferable keyrings.

> and adding keys the old way with apt-key should work too.

you mean that someone should be able to do "apt-key add $filename",
right?

Why should this require the full gpg?  why wouldn't it just do something
like:

  cp -a $filename $(mktemp --suffix=.gpg /etc/apt/trusted.gpg.d/added-key.XXXXXX)
  
Alternately, if this isn't acceptable for some reason, can we move gnupg
to Recommends: and then if someone invokes apt-key add, and gpg isn't
available, it can fail with an error message that suggests either:

 a) install the gnupg package and try again, or

 b) move the file into /etc/apt/trusted.gpg.d/

Archive signature verification really just requires public key
operations, it would be nice to not require any of the secret key
machinery if we don't need to.

          --dkg

PS i note that sm/keydb.c also has a MAX_KEYDB_RESOURCES, but it is
#defined to 20.  Since this isn't relevant to apt, i'll leave it alone
for now :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160422/1cbca5de/attachment.sig>