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

David Kalnischkies david at kalnischkies.de
Tue Aug 11 09:15:19 UTC 2015


On Tue, Aug 11, 2015 at 12:09:07AM -0400, Daniel Kahn Gillmor wrote:
> 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.

So, done'd the old #634197 based on this.  A quick look via codesearch
suggests that --refresh-keys isn't particularily widespreed in the
archive and all uses seem to be 'okay'.


What about 'blind' --recv-keys? My guess would be that this is just as
unsafe as otherwise --refresh-keys could just be a "for all keys I have
call --recv-keys key", but well, what do I know… This is relatively
common in the archive, mostly in documentation, but some real calls.


> 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

Yeah, you are right, I looked at an old gnupg DETAILS file on my system,
not the gnupg2 one… sry for the confusion.


Best regards

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/20150811/4e8caf9b/attachment.sig>


More information about the pkg-gnupg-maint mailing list