[pkg-gnupg-maint] Bug#790665: Bug#790665: gpg2 fails to import gpg2 created keyring in a gpg1 created keyring

[Daniel Kahn Gillmor]

Hi David--

Thanks for the detailed discussion here, and for your work on apt!

On Tue 2015-07-07 08:35:32 -0400, David Kalnischkies wrote:
> That is an acceptable expectation, I would just be a lot happier if that
> would be documentated somewhere. Maybe I am the only idiot, but at least
> for this idiot it is surprising that "[filename]" isn't including
> a keybox, but expecting a very specific file format which just happened
> to be the same for (simple) keyring files and hence were accepted as
> well instead of just a (maybe temporarily saved) stream. That it is
> binary doesn't help me in making it more discoverable (nor is it very
> "standard unix practice" like for that matter to have a binary stream,
> text is very much preferred… </nitpick>).
 [...]
> All I am trying to say here I guess is that this is something I wasn't
> expecting and why I wasn't. What you end up doing (or not) with that
> information is your choice. No problem for me either way now that I am
> "in the know"; I am just entertaining the possibility that I am not the
> least knowledgeable gpg user… but I might be.

I'm in full agreement with you that the documentation could be improved,
and i'm quite sure you're not the only person to be confused by this.
:( I'm having trouble at the moment getting enough distance from gpg to
be able to overhaul the documentation cleanly from a new-user
perspective, but i would happily champion any documentation patches with
upstream if you (or anyone else) wants to provide them.

fwiw, gpg(1) says "Only the gpg may modify these files." which implies
(with awkward syntax) that the files themselves are not intended for
public use.

> If that is done we can demote the gnupg dependency to a recommends (or
> suggests). Well, slightly earlier I guess as we can let the -keyring
> packages recommend gnupg for the migration handling as we did for
> debian-archive-keyring.

this approach sounds promising :)

> codesearch.d.n suggests a few places. Most are in documentation (install
> instructions) and testcode, but at the very least salt, ansible and
> puppet seem to provide modules to use apt-key adv to import keys from
> remote servers…
>
> And I know people who do --refresh-keys in cron jobs. There is actually
> a bug requesting apt to do this.

yikes, please do not do this.  --refresh-keys is only safe to do if you
have some robust verification mechanism (like gnupg's "classic" trust
model) for the keys in your keyring.  --refresh-keys is decidedly unsafe
if you ever use the raw keys as a canonical truth (e.g.,
--trust-model=always, or gpgv --keyring ).

> I am not a huge fan of either as this means there is another vector
> where MITM and such things are a threat, but oh well.

ugh, this is an absolutely terrible practice.  I suspect we can find
ways to report these as security holes if someone wants to take the time
to write them up.

> I just implemented the cat-merging, so Release file verification is
> again a gpgv-only operation in /experimental soon. /sid and earlier are
> anyway.

great!  thank you, David!

> As said, apt needs nothing, with the cat-merging and a more careful
> importing (so that the result is always a simple keyring)
> apt-key/experimental works now fine with gpg 2.1. Earlier versions
> should be fine with gpg 2.1 anyway (just that it has "unrelated" bugs).
>
> The bug was about the importing of keyboxes. If that isn't supposed to
> work that isn't a bug (expect documentation maybe). You reported your
> observation that gpgv can't deal with keyboxes already upstream. The
> slowdown is known upstream as well. --delete-keys only working on the
> first key is a bit strange from a user POV, but well, I can see why
> a unique fingerprint is a stop word…
>
> So, nothing unique to this bugreport I presume,

ok, closing this report for now; feel free to reopen it if you think we
need to...

> There is something I found just now which is a bit strange: gpgv
> --status-fd is documented in /usr/share/doc/gnupg/DETAILS.gz.
>
> In GOODSIG it says that each sig has either "GOODSIG, BADSIG or ERRSIG"
> code, which isn't true as an expired sig comes with EXPSIG. Worse, in
> VALIDSIG it is said that "This is the same as GOODSIG […] Both status
> lines are emitted for a good signature.", while as mentioned earlier
> gpgv does not emit a GOODSIG for expired sigs, but does emit VALIDSIG.
> Would be nice if the documentation could be updated to match reality.

I've sent upstream a patch for this:

  https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030117.html

Please let me know if you think it can be further improved.

> Oh, and I wonder, are there any plans to "replace" the long keyids with
> fingerprints here at some point (new names, new parameter, whatever)?
> Unlikely perhaps, but archives with the same long keyid could be fun…

For VALIDSIG at least, it should be all long fingerprints.  I'm not sure
what the plan is for replacing them in GOODSIG, ERRSIG, etc.

Regards,

        --dkg