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

[Julian Andres Klode]

On Fri, Apr 22, 2016 at 10:59:29AM -0400, Daniel Kahn Gillmor wrote:
> 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 think that's it, yes. I don't do much apt-key stuff...

(I would have written more, but I was writing on the phone just to give
a quick notice :))

> 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?

I don't think it really affects Debian people that much, it's mostly
Ubuntu systems with tens or hundreds of PPA - each PPA has its own
signing key.

> 
> 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.

I'm not sure which format apt-key add uses...

> 
> > 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)

Well, /etc/apt/trusted.gpg.d/<KEYID>.gpg would probably be even easier,
I think nobody thought about this yet?

If we had KEYID-based files, we could also easily limit the problem by
a pinning mechanism: Advertise two trusted keys in the Release file (one
active + one future key) and APT can then remember that and only pass
those keys to gpgv. (I'd love to have that pinning thing anyway, it seems
kind of nice to have...)



-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.