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 :)
Attachment:
signature.asc
Description: PGP signature