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

[David Kalnischkies]

Hello again,

picking up where I dropped the mic last month…

On Tue, Jul 07, 2015 at 12:02:42PM -0400, Daniel Kahn Gillmor wrote:
> perspective, but i would happily champion any documentation patches with
> upstream if you (or anyone else) wants to provide them.

I should be writing documentation for apt and tend to fail at it, I should
probably not be trying to documented something else… I think I am better at
misinterpreting/cristising existing and complaing about missing documentation
than actually changing it ;)


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

So, I predict it isn't a super-good idea because of bugs and the resulting threads
like #725411, but if gpg{,2} maintainers can officially declare it unsafe in
the context apt is using (aka: without web-of-trust) I would be "happy" and
have probably an easier time actively breaking these usecases – and report them
as (security) bugs…


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

That reads better, thanks!

What about the first thing I said through: In the section about GOODSIG it
claims to iterate all possible codes you could have for a sig (three)
"GOODSIG, BADSIG or ERRSIG" while it is perfectly possible to get
a EXPKEYSIG (or EXPSIG) instead, so that should probably be mentioning
all five codes.


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

I see it is commited already, but as I said I would be 'good' at
documentation nitpicking: I think it should be "… valid. This {+is+}
similar to GOODSIG …" and "or … or … or …" reads a bit strange, I would
have expected ", …, … or …". And that list is missing EXPSIG, too,
I guess (but I haven't checked if EXPSIG is actually generated by gpg).


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

Okay, I was just asking into the blue, so no worries.


Best regards from DebCamp,

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20150810/a51f13b5/attachment.sig>