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 > > 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" ? There is no need to from the APT side, apt >= 1.1 calls gpg(v)(2) consistently with single keyring (after potentially merging multiple together with cat as we discussed last year in the apt-vs-gpg2 thread). (See also #733028; the user contacted gpg upstream first about this limit, so the "problem" is acknowledged – wasn't there a plan/idea to drop that limit to 1 in the future, through?) > > 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) Something like that could work I guess, it just gets funny with '-' for stdin – and I wonder if gpg supports more things on import than the 'simple keyring format' (like keyboxes or ascii, but I haven't tried). Additionally, if you add keys multiple times this would add multiple files – and if you "update" keys this way you even have different versions of the key. No problem for gpg of course, but looks bad in 'apt-key list' and similar. I don't think that is used that often through as if you have such a file you could just as well drop the file into trusted.gpg.d by yourself nowadays & even give it a nice and friendly name. "Adding keys" by users is usually done with a 'apt-key adv --recv-key' *shudder* which frankly I have no real problem "breaking" as someone who isn't capable of installing gnupg(2) to make that work might be better of not running it… > 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/ apt-key already checks if gnupg is installed before running any command which will need it, so for a) we are set. b) we could add I guess. It checks because apt depends on gnupg since 2010 only (c6391a3b), before it was relying on the -keyring packages (namely debian-archive-keyring) to bring in gpg/gpgv "as needed" (as it is theoretically possible to use apt without signed Release files…). Personally, I don't see a problem with dropping it to Recommends nowadays as that was basically the plan all along since the introduction of trusted.gpg.d. In fact I would like to drop it to Suggests as apt-key is a niche tool likely not used on more than just "unusual" systems. (With that argument, I would even like to move gpgv to Recommends, but that is a battle for another day). > 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. That would be nice indeed. What is missing here is mostly a tool which works with public keys only – like listing them, exporting them or perhaps even encrypt something to it. I am thinking about #817805 for example which I haven't thought about much yet, but it seems hard to solve if all you have in your tool belt is gpgv… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature