[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#634197: automatically refresh keys from the GPG keyring



On Tue, Aug 11, 2015 at 10:46:32AM -0400, Antoine Beaupré wrote:
> On 2015-08-11 04:33:31, David Kalnischkies wrote:
> > Hi,
> >
> > On Sun, Jul 17, 2011 at 12:06:37PM -0400, Antoine Beaupré wrote:
> >> Now, those keys are (or can be) published on the keyservers. Why don't
> >> we have a cronjob in APT that will automatically refresh the keys on
> >> that keyring from the keyservers? It would take care of the key
> >> rotation necessary to deal with a compromise of the signing keys, but
> >> at least it would "fail closed".
> >> 
> >> I have found that the following command works pretty well for my needs:
> >> 
> >> apt-key adv --keyserver pool.sks-keyservers.net --refresh-keys
> >
> > The reason is that this isn't a secure way of getting updates for keys
> > if you don't happen to have a web-of-trust to ensure they are the keys
> > you wanted and apt hasn't.
> >
> > I had this in the back of my mind for quite a while and wanted to close
> > this earlier, but never had a conviencing source to back me up…
> > Until now as I asked gnupg{,2} maintainers and they confirmed it:
> >
> > | 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.
> >  -- Daniel Kahn Gillmor
> > Source: https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2015-August/002802.html
> >
> > So, closing as "not-a-possible-solution".
> >
> >
> > This doesn't solve the problem itself of course, but there isn't a real
> > solution for it off hand as our only secure way of talking to the
> > outside world is via this key, so if the key is no longer viable,
> > we have lost and manual intervention is needed.
> 
> My thinking here wasn't to blindly refresh the keys from the keyring,
> but to leverage the trustdb to allow only a certain set of keys to be
> trusted for authenticating packages...

I don't understand. Your suggestion in the bugreport was to run
--refresh-keys on the keyring(s) apt-key uses for authenitcation.

The problem is that this isn't possible in a secure way as Daniel
confirmed as an attacker than inject "arbitrary key[s]" into the
refreshed keyrings, so an attacker can add keys you trust for
authentication. That pretty much defeats the point…

Best regards

An a bit confused David Kalnischkies

Attachment: signature.asc
Description: Digital signature


Reply to: