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

Bug#634197: marked as done (automatically refresh keys from the GPG keyring)

Your message dated Tue, 11 Aug 2015 10:33:31 +0200
with message-id <20150811083331.GA6804@crossbow>
and subject line Re: automatically refresh keys from the GPG keyring
has caused the Debian Bug report #634197,
regarding automatically refresh keys from the GPG keyring
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
634197: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634197
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 0.8.15.1
Severity: wishlist

I maintain a third party Debian archive at http://debian.koumbit.net/,
as I am sure hundreds of others are doing for their own software (not
yet in Debian or for local packages).

If I want to revoke or update (change expiration) the PGP key of this
archive, I need to tell people:

wget http://debian.koumbit.net/debian/key.asc | apt-key add -

... which introduces yet another window of vulnerability where
arbitrary key material can be injected by an attacker. (I won't go
over the more general problem of how to add this key in the first
place, mind you...)

This works fairly well for key expiration, as people notice the error
then people will have to figure it out and run the above command. It
"fails closed".

If that key would effectively be compromised, things are much worse:
people would never notice the revoked key as they would need to update
their keyring manually at first. It "fails open". Think of the
problems you would have to distribute a revocation certificate for the
auto-signing keys in the main debian archive now.

I'll let that sync in.

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

Offtopic, I also had great joy in telling people they can verify the
autosigning key of debian.koumbit.net on their own Debian machine with
this:

apt-key adv --keyring /usr/share/keyrings/debian-maintainers.gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg --check-sigs B7C0A70A

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to fr_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2010.08.28       GnuPG archive keys of the Debian a
ii  gnupg                   1.4.11-3         GNU privacy guard - a free PGP rep
ii  libc6                   2.13-7           Embedded GNU C Library: Shared lib
ii  libgcc1                 1:4.6.1-1        GCC support library
ii  libstdc++6              4.6.1-1          GNU Standard C++ Library v3
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc                       <none>     (no description available)
ii  aptitude                      0.6.3-4    terminal-based package manager (te
ii  bzip2                         1.0.5-6    high-quality block-sorting file co
ii  dpkg-dev                      1.16.0.3   Debian package development tools
ii  lzma                          4.43-14    Compression method of 7z format in
ii  python-apt                    0.8.0      Python interface to libapt-pkg
ii  synaptic                      0.75.2     Graphical package manager

-- no debconf information

--- End Message ---
--- Begin Message --- 
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.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: