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

[Daniel Kahn Gillmor]

On Mon 2015-08-10 16:27:50 -0400, David Kalnischkies wrote:
>>> And I know people who do --refresh-keys in cron jobs. There is actually
>>> a bug requesting apt to do this.
>>
 [dkg wrote:]
>> 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…

I can declare that :)

I hereby declare that a blind --refresh-keys from a keyserver to an
apt-trusted keyring leaves the system vulnerable to arbitrary key
injection in that keyring.  The attacker can be the keyserver operator,
or they can be on the network path between the machine and the
keyserver.

Breaking these usecases and reporting them as security bugs seems fine
to me.  Please Cc: me on any such reports, i'm happy to chime in.

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

The section about GOODSIG seems to mention all six (not five -- you
missed REVKEYSIG) codes, and it has since 65eb9896 was merged.

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

hm, i think you're looking at a different version of doc/DETAILS than i
am right now, so this doesn't quite make sense to me.  But i think i've
fixed the line in question with

https://lists.gnupg.org/pipermail/gnupg-devel/2015-August/030215.html

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20150811/89d0f49a/attachment.sig>