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

[David Kalnischkies]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160422/25ca7d91/attachment.sig>