Debian Bug report logs - #558784
apt: re-adds removed keys

version graph

Package: apt; Maintainer for apt is APT Development Team <deity@lists.debian.org>; Source for apt is src:apt.

Reported by: Tollef Fog Heen <tfheen@err.no>

Date: Mon, 30 Nov 2009 14:57:01 UTC

Severity: serious

Tags: squeeze-ignore, wheezy-ignore

Found in version apt/0.7.24

Fixed in version 0.9.10

Done: David Kalnischkies <kalnischkies@gmail.com>

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Mon, 30 Nov 2009 14:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
New Bug report received and forwarded. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 30 Nov 2009 14:57:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: submit@bugs.debian.org
Subject: apt: re-adds removed keys
Date: Mon, 30 Nov 2009 15:51:43 +0100
Package: apt
Severity: serious
Version: 0.7.24
Justification: overwrites local configuration changes

I have removed some keys from my apt keyring, but it seems like apt
always re-adds them when configuring:

shashlik# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/6070D3A1 2006-11-20 [expired: 2009-07-01]
uid                  Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>

pub   1024D/ADB11277 2006-09-17
uid                  Etch Stable Release Key <debian-release@lists.debian.org>

[...]

shashlik# apt-key remove ADB11277
OK
shashlik# apt-key update
gpg: key 6070D3A1: "Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>" not changed
gpg: key ADB11277: public key "Etch Stable Release Key <debian-release@lists.debian.org>" imported
gpg: key BBE55AB3: "Debian-Volatile Archive Automatic Signing Key (4.0/etch)" not changed
gpg: key F42584E6: "Lenny Stable Release Key <debian-release@lists.debian.org>" not changed
gpg: key 55BE302B: "Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>" not changed
gpg: key 6D849617: "Debian-Volatile Archive Automatic Signing Key (5.0/lenny)" not changed
gpg: Total number processed: 6
gpg:               imported: 1
gpg:              unchanged: 5
gpg: no ultimately trusted keys found
shashlik# apt-key list
/etc/apt/trusted.gpg
--------------------

[...]

pub   1024D/ADB11277 2006-09-17
uid                  Etch Stable Release Key <debian-release@lists.debian.org>

shashlik# 

from apt.postinst:

case "$1" in
    configure)

        if ! test -f /etc/apt/trusted.gpg; then
                cp /usr/share/apt/debian-archive.gpg /etc/apt/trusted.gpg
        fi

	apt-key update

    ;;

so it is actually a double policy violation: removing
/etc/apt/trusted.gpg is a perfectly legal configuration change that apt
must not override.  Ditto, removing a key is a perfectly legal
configuration change that apt must not override in its postinst.

-- 
Tollef Fog Heen 
UNIX is user friendly, it's just picky about who its friends are




Reply sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
You have taken responsibility. (Mon, 14 Dec 2009 11:39:04 GMT) Full text and rfc822 format available.

Notification sent to Tollef Fog Heen <tfheen@err.no>:
Bug acknowledged by developer. (Mon, 14 Dec 2009 11:39:04 GMT) Full text and rfc822 format available.

Message #10 received at 558784-done@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Tollef Fog Heen <tfheen@err.no>, 558784-done <558784-done@bugs.debian.org>
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Mon, 14 Dec 2009 12:35:56 +0100
Hi Tollef Fog Heen,

2009/11/30 Tollef Fog Heen <tfheen@err.no>:
>
> Package: apt
> Severity: serious
> Version: 0.7.24
> Justification: overwrites local configuration changes
Thanks for your report - unfortunately i think this report is invalid
and i therefore close it for the following reasons.
Feel free to ask and/or reopen it, but please read the reasons
below first and be prepared to give good reasons if you disagree.

While i could agree with you on a (very high) metalevel that this could
be a valid configuration change, i have a few very simple practical
reasons why not:
- first of all: /etc/apt/trusted.gpg is not a configuration file
  [in dpkg sense] yes - it looks like one as it is in /etc - and it is in
  some ways a configuration file, but not directly if you compare it to
  "normal" configuration files like xorg.conf.
- apt depends on debian-archive-keyring. So it explicitly says that it
  requires the complete keyring to work correctly. A administrator who
  removes parts of this keyring therefore doesn't make a valid configuration
  change - he breaks the dependency apt has causing apt to do possibly
  strange things (behavior of applications with broken dependencies is
  undefined) - Including reimporting the keyring to fix it.
  (A segfault would be also possible.)
- A keyring is a keyring because the keys together form a ring of trust.
  If you don't trust a key in the ring, you can't trust the keyring
  (if this wouldn't be the case a keyring should be called "loosely coupled
  group of keys"), so if you remove a key you effectively remove the keyring.
  This is disallowed by the dependency (as said in the previous point).


Best regards / Mit freundlichen Grüßen,

David "DonKult" Kalnischkies




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Wed, 16 Dec 2009 07:45:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Wed, 16 Dec 2009 07:45:13 GMT) Full text and rfc822 format available.

Message #15 received at 558784@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 558784 <558784@bugs.debian.org>
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Wed, 16 Dec 2009 08:36:37 +0100
reopen 558784
thanks

]] David Kalnischkies 

| While i could agree with you on a (very high) metalevel that this could
| be a valid configuration change, i have a few very simple practical
| reasons why not:
|
| - first of all: /etc/apt/trusted.gpg is not a configuration file
|   [in dpkg sense] yes - it looks like one as it is in /etc - and it is in
|   some ways a configuration file, but not directly if you compare it to
|   "normal" configuration files like xorg.conf.

Yes, it's a configuration file.  If it's not, this is an FHS violation
as only configuration files should be in /etc. Dpkg does not have a
concept of configuration files, it has a concept of conffiles which are
shipped in the package.  The trusted.gpg file is not a conffile.  That
it is not a text file is irrelevant
here.  /etc/ssl/certs/ca-certificates.crt isn't a normal text file you
sit down and configure either.

As to whether it's a valid configuration change: why is it not?  Why is
adding more keys to the keyring valid if removing keys is not?  Why does
even apt-key provide a «remove» command if that's not a valid change of
configuration?

| - apt depends on debian-archive-keyring. So it explicitly says that it
|   requires the complete keyring to work correctly. A administrator who
|   removes parts of this keyring therefore doesn't make a valid configuration
|   change - he breaks the dependency apt has causing apt to do possibly
|   strange things (behavior of applications with broken dependencies is
|   undefined) - Including reimporting the keyring to fix it.
|   (A segfault would be also possible.)

The dependency isn't broken, I have d-a-k installed on the system, apt
and apt-key can access that keyring just fine, if not apt-key update
would not work.

If an application segfaults because of a missing key in a keyring,
that's surely a bug in the package; this whole argument sounds like a
strawman to me.

| - A keyring is a keyring because the keys together form a ring of trust.
|   If you don't trust a key in the ring, you can't trust the keyring
|   (if this wouldn't be the case a keyring should be called "loosely coupled
|   group of keys"), so if you remove a key you effectively remove the keyring.
|   This is disallowed by the dependency (as said in the previous point).

No.  GPG has a trust database where I can tell it how much I trust the
various keys.  That does not have anything to do with whether they are
in a single file or not.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 16 Dec 2009 07:45:23 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sat, 19 Dec 2009 13:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julian Andres Klode <jak@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 19 Dec 2009 13:27:03 GMT) Full text and rfc822 format available.

Message #22 received at 558784@bugs.debian.org (full text, mbox):

From: Julian Andres Klode <jak@debian.org>
To: Tollef Fog Heen <tfheen@err.no>, 558784@bugs.debian.org
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Sat, 19 Dec 2009 14:22:27 +0100
Am Montag, den 30.11.2009, 15:51 +0100 schrieb Tollef Fog Heen:
> Package: apt
> Severity: serious
> Version: 0.7.24
> Justification: overwrites local configuration changes
> 
> I have removed some keys from my apt keyring, but it seems like apt
> always re-adds them when configuring:
> 
> shashlik# apt-key list
> /etc/apt/trusted.gpg
> --------------------
> pub   1024D/6070D3A1 2006-11-20 [expired: 2009-07-01]
> uid                  Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>
> 
> pub   1024D/ADB11277 2006-09-17
> uid                  Etch Stable Release Key <debian-release@lists.debian.org>
> 
> [...]
> 
> shashlik# apt-key remove ADB11277
> OK
> shashlik# apt-key update
> gpg: key 6070D3A1: "Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>" not changed
> gpg: key ADB11277: public key "Etch Stable Release Key <debian-release@lists.debian.org>" imported
> gpg: key BBE55AB3: "Debian-Volatile Archive Automatic Signing Key (4.0/etch)" not changed
> gpg: key F42584E6: "Lenny Stable Release Key <debian-release@lists.debian.org>" not changed
> gpg: key 55BE302B: "Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>" not changed
> gpg: key 6D849617: "Debian-Volatile Archive Automatic Signing Key (5.0/lenny)" not changed
> gpg: Total number processed: 6
> gpg:               imported: 1
> gpg:              unchanged: 5
> gpg: no ultimately trusted keys found
> shashlik# apt-key list
> /etc/apt/trusted.gpg
> --------------------
> 
> [...]
> 
> pub   1024D/ADB11277 2006-09-17
> uid                  Etch Stable Release Key <debian-release@lists.debian.org>
> 
> shashlik# 
> 
> from apt.postinst:
> 
> case "$1" in
>     configure)
> 
>         if ! test -f /etc/apt/trusted.gpg; then
>                 cp /usr/share/apt/debian-archive.gpg /etc/apt/trusted.gpg
>         fi
> 
> 	apt-key update
> 
>     ;;
> 
> so it is actually a double policy violation: removing
> /etc/apt/trusted.gpg is a perfectly legal configuration change that apt
> must not override.  Ditto, removing a key is a perfectly legal
> configuration change that apt must not override in its postinst.
We should move it to /var/lib/apt, cupt does this and it seems to be a
much more logical location for such data.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.






Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sat, 19 Dec 2009 13:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 19 Dec 2009 13:30:03 GMT) Full text and rfc822 format available.

Message #27 received at 558784@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Julian Andres Klode <jak@debian.org>
Cc: 558784@bugs.debian.org
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Sat, 19 Dec 2009 14:27:06 +0100
]] Julian Andres Klode 

| > so it is actually a double policy violation: removing
| > /etc/apt/trusted.gpg is a perfectly legal configuration change that apt
| > must not override.  Ditto, removing a key is a perfectly legal
| > configuration change that apt must not override in its postinst.
|
| We should move it to /var/lib/apt, cupt does this and it seems to be a
| much more logical location for such data.

Please note that it should still be possible to disable apt keys an
admin does not trust or want to ensure are not installed onto the
system.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Fri, 19 Feb 2010 16:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Fri, 19 Feb 2010 16:03:05 GMT) Full text and rfc822 format available.

Message #32 received at 558784@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: 558784 <558784@bugs.debian.org>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Fri, 19 Feb 2010 17:01:26 +0100
I still don't think it is a real bug as APT has a hard dependency on
debian-archive-keyring ~ it doesn't recommend this keys, it says:
You must have ALL these keys installed to use APT correctly and
on the other hand i see no reason why someone want to remove a
key from the debian-archive-keyring which would be not better be
done by the package itself for all users…
(we could questioning the dependency itself now of course)


But anyway, APT 0.7.25.1 includes some code to help with this -
let us call it - usecase: trusted.gpg can be split into fragment files.
Current status is to ship squeeze with support for these fragments
while not actually use it to be on the save side in regards to backports
and co and to recommend usage directly after squeeze release, so
i would tag it squeeze-ignore, but that is a decision up to the release team -
who is btw also responsible for debian-archive-keyring and therefore
the biggest player in a possible keyring-transition…

The big advantage is that we would no longer need apt-key and
therefore gpg to add/remove keys to apt's trusted keyring:
Simple mv, cp & rm would be enough for managing, gpgv for usage and
gnupg could be dropped from Priority:important-list (see #387688).

The small advantage for you would be that this fragment files could
be real dpkg conf-files and neither apt nor debian-archive-keyring would need
special code (aka apt-key update) to ensure a correctly setupped keyring.

The files are still binary files so dpkgs conffile handling wouldn't be that
helpful, but at least the md5sum mismatch would be noticeable…
(Yes, binary is required here as gpgv only supports the binary format)
On the other hand the keyrings could be fragmented in
debian-archive-keyring-lenny.gpg, debian-archive-keyring-squeeze.gpg,
whatever.gpg so the situation would be in 99% of all cases
a removed conffile instead of a modified… (if modified at all).

Oh, and yes, after that apt could lower the debian-archive-keyring
dependency to recommends as it wouldn't need to set it up any longer,
but i would like to defer this discussion to some point after squeeze…


Best regards / Mit freundlichen Grüßen,

David Kalnischkies


P.S.: I fail to see why /var/lib is a better place for trusted keys than /etc.
APT doesn't modify it while running, it isn't bound to a specific host
(why i should not share my trusted keys between my boxes as i do
 with my other APT settings?) and users can modify it (to some extend).




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sat, 20 Feb 2010 11:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 20 Feb 2010 11:57:03 GMT) Full text and rfc822 format available.

Message #37 received at 558784@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 558784 <558784@bugs.debian.org>
Subject: Re: Bug#558784: apt: re-adds removed keys
Date: Sat, 20 Feb 2010 12:54:46 +0100
]] David Kalnischkies 

| I still don't think it is a real bug as APT has a hard dependency on
| debian-archive-keyring ~ it doesn't recommend this keys, it says:
| You must have ALL these keys installed to use APT correctly and
| on the other hand i see no reason why someone want to remove a
| key from the debian-archive-keyring which would be not better be
| done by the package itself for all users…
| (we could questioning the dependency itself now of course)

Let's agree to disagree about this? :-)

[...]

| The big advantage is that we would no longer need apt-key and
| therefore gpg to add/remove keys to apt's trusted keyring:
| Simple mv, cp & rm would be enough for managing, gpgv for usage and
| gnupg could be dropped from Priority:important-list (see #387688).

Oh, this is great news.

| The small advantage for you would be that this fragment files could
| be real dpkg conf-files and neither apt nor debian-archive-keyring would need
| special code (aka apt-key update) to ensure a correctly setupped keyring.
| 
| The files are still binary files so dpkgs conffile handling wouldn't be that
| helpful, but at least the md5sum mismatch would be noticeable…
| (Yes, binary is required here as gpgv only supports the binary format)
| On the other hand the keyrings could be fragmented in
| debian-archive-keyring-lenny.gpg, debian-archive-keyring-squeeze.gpg,
| whatever.gpg so the situation would be in 99% of all cases
| a removed conffile instead of a modified… (if modified at all).

Sure, binary files in /etc is somewhat icky from a diff(1) point of
view, but I at least can live with that.

| Oh, and yes, after that apt could lower the debian-archive-keyring
| dependency to recommends as it wouldn't need to set it up any longer,
| but i would like to defer this discussion to some point after squeeze…

Works for me.

Thanks for your work on this. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Fri, 11 Jun 2010 22:15:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Torsten Landschoff <t.landschoff@gmx.net>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Fri, 11 Jun 2010 22:15:12 GMT) Full text and rfc822 format available.

Message #42 received at 558784@bugs.debian.org (full text, mbox):

From: Torsten Landschoff <t.landschoff@gmx.net>
To: 558784@bugs.debian.org
Subject: Isn't this a security problem?
Date: Sat, 12 Jun 2010 00:03:30 +0200
I would consider this to be a critical issue as it could become a security
problem.

Let's assume an archive key is compromised. As an admin reading this on
some information channel (irc, twitter, lwn.net, whatever) I would just
remove the key as shown by Tollef.

Only by reading this bug report I do know now that this plainly would not
work. Instead apt-key will reenable this key given any chance.

That sound to me like reenabling a root account or password authentication
for ssh style, something that should be up to the admin to decide. Having
a system override such a decision against me as the admin sounds like a
nightmare to me, something I would not accept from a trusted Debian system.

So, does this bug still apply?

Greetings, Torsten




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Mon, 14 Jun 2010 11:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 14 Jun 2010 11:33:03 GMT) Full text and rfc822 format available.

Message #47 received at 558784@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Torsten Landschoff <t.landschoff@gmx.net>, 558784 <558784@bugs.debian.org>
Subject: Re: Bug#558784: Isn't this a security problem?
Date: Mon, 14 Jun 2010 13:25:25 +0200
2010/6/12 Torsten Landschoff <t.landschoff@gmx.net>:
> I would consider this to be a critical issue as it could become a security
> problem.
>
> Let's assume an archive key is compromised. As an admin reading this on
> some information channel (irc, twitter, lwn.net, whatever) I would just
> remove the key as shown by Tollef.
>
> Only by reading this bug report I do know now that this plainly would not
> work. Instead apt-key will reenable this key given any chance.

Not at any chance and for any key:
It will do so only for the debian-archive-keyring AND
only on update for the package apt and/or debian-archive-keyring.
(with complete gpg import output in the log btw)
If the debian-archive-keyring is ever compromised the attacker has
the possibility to provide different apt/debian-archive-keyring packages
anyway so you better not upgrade as long as the archive doesn't
have a new key (which you have validated and installed manually) --
and in this event the debian-archive-keyring package will be one
of the first packages updated in the archive (removing the old,
installing the new key - just to be sure and for all the users which
haven't done it manually…).

Other keyring packages normally add themselves to the database
on an install/upgrade of these packages automatically - if you don't
want that what is the point of installing these keyring packages?


> So, does this bug still apply?

Still applies as the fragments file infrastructure is not used so far.
As said earlier i intend to promote that a bit after squeeze release
to have a smoother transition (keyrings are normally without a problem
backportable between different releases - breaking that feels a bit ugly.)

The difference is not big through. Instead of calling apt-key or doing some
manual gpg calling a package drops a file into /etc/apt/trusted.gpg.d/
The file is still binary so manual editing is not a good idea (TM)
but at least someone who really wants to remove keys from a keyring file
will get the benefits of dpkgs conffile handling - in terms of that he will
notice that you have changed something, not so much that you can easily
see what was changed…

But, and that is what should help in this regard a bit is, that most keyrings
are actually just one key, so the action can be broken down to a removed
config file instead… This just need support by the maintainer of the keyring,
so the debian-archive-keyring could e.g. be split into debian-lenny.gpg,
debian-squeeze.gpg, debian-next-big-thing.gpg and so on.

You might ask "why binary?" now, but APT internally uses gpgv for the
validation which only understands binaries and not the ascii-amored stuff.
(gpg is only used to import keyrings into the trusted keyring by the
keyrings - if we switch to fragment files the gpg is no longer needed…)


Best regards,

David Kalnischkies




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Wed, 23 Jun 2010 14:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Wed, 23 Jun 2010 14:27:06 GMT) Full text and rfc822 format available.

Message #52 received at 558784@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 558784@bugs.debian.org, Torsten Landschoff <t.landschoff@gmx.net>
Subject: Re: Bug#558784: Isn't this a security problem?
Date: Wed, 23 Jun 2010 16:23:55 +0200
David Kalnischkies <kalnischkies+debian@gmail.com> writes:

> 2010/6/12 Torsten Landschoff <t.landschoff@gmx.net>:
>> I would consider this to be a critical issue as it could become a security
>> problem.
>>
>> Let's assume an archive key is compromised. As an admin reading this on
>> some information channel (irc, twitter, lwn.net, whatever) I would just
>> remove the key as shown by Tollef.
>>
>> Only by reading this bug report I do know now that this plainly would not
>> work. Instead apt-key will reenable this key given any chance.
>
> Not at any chance and for any key:
> It will do so only for the debian-archive-keyring AND
> only on update for the package apt and/or debian-archive-keyring.
> (with complete gpg import output in the log btw)
> If the debian-archive-keyring is ever compromised the attacker has
> the possibility to provide different apt/debian-archive-keyring packages
> anyway so you better not upgrade as long as the archive doesn't
> have a new key (which you have validated and installed manually) --
> and in this event the debian-archive-keyring package will be one
> of the first packages updated in the archive (removing the old,
> installing the new key - just to be sure and for all the users which
> haven't done it manually…).
>
> Other keyring packages normally add themselves to the database
> on an install/upgrade of these packages automatically - if you don't
> want that what is the point of installing these keyring packages?
>
>
>> So, does this bug still apply?
>
> Still applies as the fragments file infrastructure is not used so far.
> As said earlier i intend to promote that a bit after squeeze release
> to have a smoother transition (keyrings are normally without a problem
> backportable between different releases - breaking that feels a bit ugly.)
>
> The difference is not big through. Instead of calling apt-key or doing some
> manual gpg calling a package drops a file into /etc/apt/trusted.gpg.d/
> The file is still binary so manual editing is not a good idea (TM)
> but at least someone who really wants to remove keys from a keyring file
> will get the benefits of dpkgs conffile handling - in terms of that he will
> notice that you have changed something, not so much that you can easily
> see what was changed…
>
> But, and that is what should help in this regard a bit is, that most keyrings
> are actually just one key, so the action can be broken down to a removed
> config file instead… This just need support by the maintainer of the keyring,
> so the debian-archive-keyring could e.g. be split into debian-lenny.gpg,
> debian-squeeze.gpg, debian-next-big-thing.gpg and so on.
>
> You might ask "why binary?" now, but APT internally uses gpgv for the
> validation which only understands binaries and not the ascii-amored stuff.
> (gpg is only used to import keyrings into the trusted keyring by the
> keyrings - if we switch to fragment files the gpg is no longer needed…)
>
>
> Best regards,
>
> David Kalnischkies

That would complicate things when using

deb [keyring=debian-lenny.gpg] http://ftp.debian.org/debian stable main

The idea of specifying a specific keyring is so that one compromised key
will not endanger all sources.list entries to attacks.

But I guess having to change the keyring name from debian-lenny.gpg to
debian-squeeze.gpg when upgrading to a new major release would be
acceptable. Just don't have it change name at will or for point/security
releases. There could also be a debian-stable.gpg -> debian-lenny.gpg
symlink.


Since I'm quite opposed to non human readable conffiles: Why is the
keyring a conffile? Why not have the packages keyring in
/usr/lib/apt/trusted.gpg.d/ and user keyrings in
/etc/apt/trusted.gpg.d/ or /usr/local/apt/trusted.gpg.d/? But I don't
know how one would go about removing a key then.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Mon, 28 Jun 2010 10:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 28 Jun 2010 10:39:03 GMT) Full text and rfc822 format available.

Message #57 received at 558784@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 558784 <558784@bugs.debian.org>, Torsten Landschoff <t.landschoff@gmx.net>
Subject: Re: Bug#558784: Isn't this a security problem?
Date: Mon, 28 Jun 2010 12:35:38 +0200
2010/6/23 Goswin von Brederlow <goswin-v-b@web.de>:
> That would complicate things when using
>
> deb [keyring=debian-lenny.gpg] http://ftp.debian.org/debian stable main
>
> The idea of specifying a specific keyring is so that one compromised key
> will not endanger all sources.list entries to attacks.

In theory you could support a list of keyrings in your trusted proposals
(which is fine for me btw) or as far as i know the recommend line currently is
to use the codename of the release instead of 'stable' so (maybe automatic)
actions like "apt-get upgrade" can not end in a "lenn-eze"…


> Since I'm quite opposed to non human readable conffiles: Why is the
> keyring a conffile? Why not have the packages keyring in
> /usr/lib/apt/trusted.gpg.d/ and user keyrings in
> /etc/apt/trusted.gpg.d/ or /usr/local/apt/trusted.gpg.d/? But I don't
> know how one would go about removing a key then.

The problem with /usr/lib/apt is that a file you delete or change will
appear unchanged again with the next upgrade of the package.
Something which seems to be disliked (in this bugreport). ;)
Binary file isn't my favorite either, but beside that gpgv doesn't
support ascii-amored files it wouldn't change much anyway:
I (and many others too) can't read ascii-armored keys…
And if it really boils down to a "file exists or not" it is the same.

/etc also as it is a user decision which keyrings he might want to trust
(or not) and that doesn't always boils down to a complete keyring package.


Best regards,

David Kalnischkies




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Mon, 23 Aug 2010 19:09:04 GMT) Full text and rfc822 format available.

Message #60 received at 558784@bugs.debian.org (full text, mbox):

From: Carsten Hey <carsten@debian.org>
To: 558784@bugs.debian.org
Cc: 387688@bugs.debian.org
Subject: Bug#558784: see discussion in related #387688
Date: Mon, 23 Aug 2010 20:54:09 +0200
Hi,

in the related bug "#387688 - debian-archive-keyring: superfluous
dependency on gnupg?" has been some discussion recently.  A part of this
discussion was sent to debian-release@l.d.o.  Many things discussed are
basically the same in both bugs, others only appear only in one bug,
e.g., mentioned Phillip Kern a possible symlinking of keyfiles from /etc
to /var.

I did not assume that someone intends to fix this for Squeeze and wanted
to assure a clean upgrade path from Squeeze if it gets fixed in
Squezze+1.  Thus I asked if the release team would be ok with making
apt/Squeeze depend on gnupg (why this is important is explained in
#387688) - experimental already contains this dependency so it will
presumably be in Squeeze.

If this bug gets fixed in Squeeze it might be sane to add a gnupg
dependency to apt/Lenny in the next point release.

Regards
Carsten




Added tag(s) squeeze-ignore. Request was from "Adam D. Barratt" <adam@adam-barratt.org.uk> to control@bugs.debian.org. (Sun, 03 Oct 2010 10:33:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Fri, 02 Mar 2012 15:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Helmut Grohne <helmut@subdivi.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Fri, 02 Mar 2012 15:45:04 GMT) Full text and rfc822 format available.

Message #67 received at 558784@bugs.debian.org (full text, mbox):

From: Helmut Grohne <helmut@subdivi.de>
To: 558784@bugs.debian.org
Cc: 558784-submitter@bugs.debian.org, packages@release.debian.org
Subject: status of this bug?
Date: Fri, 2 Mar 2012 16:35:57 +0100
Hi,

First of all let me give a summary (corrections welcome):

/etc/apt/trusted.gpg is a binary gpg keyring that by default contains
the keys used to verify the release files. It is changed by apt-key
during upgrades of either apt or debian-archive-keyring. This change may
overwrite user changes (removal of keys) and is thus technically a
policy violation (either direct or via FHS). It is not agreed upon
whether such a user change is to be supported. However the current
implementation and documentation of apt-key do support removal of keys.
The resulting behaviour may confuse a user and can be interpreted as a
security issue.

Since the original report things have changed a bit. apt has gained a
/etc/apt/trusted.gpg.d which can be maintained in a strictly policy
compliant manner (using binary conffiles). However the feature could not
be employed in squeeze to support upgrades from lenny. The bug was thus
tagged squeeze-ignore. Upgrade issues have now vanished since slipping
releases is not considered supported.

Possible solution?

According to my understanding of the issue debian-archive-keyring could
be changed to provide conffiles in /etc/apt/trusted.gpg.d. This way of
doing things would completely obsolete apt-key and thus close this bug.
There are a few options to implement those conffiles.
1 binary regular files
1.1 one file per key
1.2 one file per suite
1.2 one big file (i.e. copy debian-archive-keyring.gpg)
2 symbolic links
2.1 one link per key
2.2 one link per suite
2.2 one link to debian-archive-keyring.gpg

Using regular files might be easier to implement, because shipping those
files in /etc makes them conffiles. Using symbolic links may be a
cleaner solution. Using more files provides more (or easier) flexibility
to the user and therefore seems preferable even though it causes more
work. In order to support the current apt-key the
debian-archive-removed-keys.gpg would need to include all present keys
(and thus clean trusted.gpg). The change would again loose user
configuration, but this seems unavoidable to me. After letting a further
release pass, apt-key could simply be dropped from apt. This bug would
need to be tagged wheezy-ignore. Is this solution doable?

If yes, I would clone this bug, reassign it to debian-archive-keyring
and block the original bug.

If not, what are the current options? Is there anyone else working on
this issue?

Helmut




Message sent on to Tollef Fog Heen <tfheen@err.no>:
Bug#558784. (Fri, 02 Mar 2012 15:45:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Tue, 06 Mar 2012 13:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Tue, 06 Mar 2012 13:15:05 GMT) Full text and rfc822 format available.

Message #75 received at 558784@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Helmut Grohne <helmut@subdivi.de>
Cc: 558784@bugs.debian.org, 558784-submitter@bugs.debian.org, packages@release.debian.org
Subject: Re: Bug#558784: status of this bug?
Date: Tue, 06 Mar 2012 14:14:00 +0100
]] Helmut Grohne 

> Using regular files might be easier to implement, because shipping those
> files in /etc makes them conffiles. Using symbolic links may be a
> cleaner solution. Using more files provides more (or easier) flexibility
> to the user and therefore seems preferable even though it causes more
> work. In order to support the current apt-key the
> debian-archive-removed-keys.gpg would need to include all present keys
> (and thus clean trusted.gpg). The change would again loose user
> configuration, but this seems unavoidable to me.

Well, it would be reasonable to:

ship all keys in keyring package, as symlinks or files in /etc
for each key in $shipped_keyring:
  if key not present in /etc/apt/trusted.gpg and we're upgrading from $flag_version
    remove /etc/apt/trusted.gpg.d/$key (if it's the right key)

This will preserve user changes just fine, AFAICS?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Message sent on to Tollef Fog Heen <tfheen@err.no>:
Bug#558784. (Tue, 06 Mar 2012 13:15:43 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Wed, 07 Mar 2012 16:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Wed, 07 Mar 2012 16:39:03 GMT) Full text and rfc822 format available.

Message #83 received at 558784@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Helmut Grohne <helmut@subdivi.de>, 558784@bugs.debian.org, 558784-submitter@bugs.debian.org, packages@release.debian.org
Subject: Re: Bug#558784: status of this bug?
Date: Wed, 7 Mar 2012 17:34:58 +0100
On Fri, Mar 2, 2012 at 16:35, Helmut Grohne <helmut@subdivi.de> wrote:
> Possible solution?
>
> According to my understanding of the issue debian-archive-keyring could
> be changed to provide conffiles in /etc/apt/trusted.gpg.d. This way of
> doing things would completely obsolete apt-key and thus close this bug.

apt-key isn't going to be obsoleted. The intend is to remove the need for
'apt-key update' - the rest of the included features are sometimes needed
regardless of if you use fragment files or not (like, 'apt-key list' or managing
the (now/then) user-keyring trusted.gpg).

For the rest of the topic have a look at debian-archive-keyring/experimental
which uses a symlink in the fragmented directory - i am personally not
very keen on using symlinks for this, but i have already commented on
that to no avail (beside providing a try in implementing a 'fragmented'
keyring by having each key in a separated file), but maybe you have
more luck:
http://lists.debian.org/debian-release/2011/10/msg00373.html


Best regards

David Kalnischkies




Message sent on to Tollef Fog Heen <tfheen@err.no>:
Bug#558784. (Wed, 07 Mar 2012 16:39:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Wed, 07 Mar 2012 17:21:10 GMT) Full text and rfc822 format available.

Message #89 received at 558784@bugs.debian.org (full text, mbox):

From: Philipp Kern <pkern@debian.org>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: Helmut Grohne <helmut@subdivi.de>, 558784@bugs.debian.org, 558784-submitter@bugs.debian.org, packages@release.debian.org
Subject: Re: Bug#558784: status of this bug?
Date: Wed, 7 Mar 2012 18:16:03 +0100
[Message part 1 (text/plain, inline)]
On Wed, Mar 07, 2012 at 05:34:58PM +0100, David Kalnischkies wrote:
> For the rest of the topic have a look at debian-archive-keyring/experimental
> which uses a symlink in the fragmented directory - i am personally not
> very keen on using symlinks for this, but i have already commented on
> that to no avail (beside providing a try in implementing a 'fragmented'
> keyring by having each key in a separated file), but maybe you have
> more luck:
> http://lists.debian.org/debian-release/2011/10/msg00373.html

FWIW your idea didn't look insane.  I haven't come back to this yet, but if we
get to a solution for wheezy it will probably be near yours.

(I.e. it was just a time problem on my side so far.)

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@0x539.de                         Wanna-Build Admin
  `-    finger pkern/key@db.debian.org
[signature.asc (application/pgp-signature, inline)]

Message sent on to Tollef Fog Heen <tfheen@err.no>:
Bug#558784. (Wed, 07 Mar 2012 17:21:24 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sun, 30 Sep 2012 18:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to anarcat <anarcat@anarcat.ath.cx>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 30 Sep 2012 18:03:06 GMT) Full text and rfc822 format available.

Message #97 received at 558784@bugs.debian.org (full text, mbox):

From: anarcat <anarcat@anarcat.ath.cx>
To: 558784@bugs.debian.org
Subject: any progress on apt-key update (#558784)?
Date: Sun, 30 Sep 2012 13:57:54 -0400
[Message part 1 (text/plain, inline)]
tag 558784 + patch
thanks

Any progress here? This is still a critical bug blocking the wheezy
release yet it hasn't seen any progress even though there is a patch
waiting...

Nobody seemed to express any explicit concern with the patch, why
shouldn't we just go ahead and NMU that?

A.

-- 
The illusion of freedom will continue as long as it's profitable to
continue the illusion. At the point where the illusion becomes too
expensive to maintain, they will just take down the scenery, they will
pull back the curtains, they will move the tables and chairs out of
the way and you will see the brick wall at the back of the theater.
                         - Frank Zappa
[signature.asc (application/pgp-signature, inline)]

Added tag(s) patch. Request was from anarcat <anarcat@anarcat.ath.cx> to control@bugs.debian.org. (Sun, 30 Sep 2012 18:03:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Mon, 12 Nov 2012 02:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Gilbert <mgilbert@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 12 Nov 2012 02:27:03 GMT) Full text and rfc822 format available.

Message #104 received at 558784@bugs.debian.org (full text, mbox):

From: Michael Gilbert <mgilbert@debian.org>
To: 558784@bugs.debian.org
Subject: apt: re-adds removed keys
Date: Sun, 11 Nov 2012 21:25:46 -0500
control: tag -1 -patch

> Nobody seemed to express any explicit concern with the patch, why
> shouldn't we just go ahead and NMU that?

I think you may be referencing:
http://lists.debian.org/debian-release/2011/10/msg00373.html

That doesn't actually do anything to address this issue.

Best wishes,
Mike



Removed tag(s) patch. Request was from Michael Gilbert <mgilbert@debian.org> to 558784-submit@bugs.debian.org. (Mon, 12 Nov 2012 02:27:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sun, 16 Dec 2012 10:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to alberto fuentes <pajaro@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 16 Dec 2012 10:36:03 GMT) Full text and rfc822 format available.

Message #111 received at 558784@bugs.debian.org (full text, mbox):

From: alberto fuentes <pajaro@gmail.com>
To: debian-release@lists.debian.org
Cc: 558784@bugs.debian.org
Subject: Request for wheezy-ignore for Bug#558784 apt: re-adds removed keys
Date: Sun, 16 Dec 2012 11:32:13 +0100
[Message part 1 (text/plain, inline)]
This bug has been already tagges as squeezy-ignore... and there seems to
not be enough interest in fixig it
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#558784; Package apt. (Sat, 26 Jan 2013 15:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 26 Jan 2013 15:00:03 GMT) Full text and rfc822 format available.

Message #116 received at 558784@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: alberto fuentes <pajaro@gmail.com>
Cc: debian-release@lists.debian.org, 558784@bugs.debian.org
Subject: Re: Request for wheezy-ignore for Bug#558784 apt: re-adds removed keys
Date: Sat, 26 Jan 2013 14:56:25 +0000
Control: tags -1 + wheezy-ignore

On Sun, 2012-12-16 at 11:32 +0100, alberto fuentes wrote:
> This bug has been already tagges as squeezy-ignore... and there seems
> to not be enough interest in fixig it

I don't think there's time to get a fix in now in any case, so agreed.

Regards,

Adam




Added tag(s) wheezy-ignore. Request was from "Adam D. Barratt" <adam@adam-barratt.org.uk> to 558784-submit@bugs.debian.org. (Sat, 26 Jan 2013 15:00:03 GMT) Full text and rfc822 format available.

Reply sent to David Kalnischkies <kalnischkies@gmail.com>:
You have taken responsibility. (Tue, 13 Aug 2013 12:27:05 GMT) Full text and rfc822 format available.

Notification sent to Tollef Fog Heen <tfheen@err.no>:
Bug acknowledged by developer. (Tue, 13 Aug 2013 12:27:05 GMT) Full text and rfc822 format available.

Message #123 received at 558784-done@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies@gmail.com>
To: 558784-done@bugs.debian.org
Subject: Bug#558784: marked as done (apt: re-adds removed keys)
Date: Tue, 13 Aug 2013 14:23:55 +0200
Version: 0.9.10

Hi *,

This is a manual mail to notify the BTS about the fact that after two
ignore tags and a few days of coding all pieces final felt together
to be able to close this RC bug - but I missed to do the simplest thing
out of all the required changes: add a Closes: tag…
(very promising for the quality of the following indeed)

So here you go:

apt (0.9.10) unstable; urgency=low

  The "Hello to Debconf" upload
[…]
  * always use our own trustdb.gpg in apt-key
  * use a tmpfile for trustdb.gpg in apt-key.
    Thanks to Andreas Beckmann for the initial patch! (Closes: #687611)
  * do not double-slash paths in apt-key (Closes: 665411)
  * make the keyring locations in apt-key configurable
  * let apt-key del work better with softlink and single key keyrings
  * do not call 'apt-key update' in apt.postinst
[…]
 -- Michael Vogt <mvo@debian.org>  Mon, 12 Aug 2013 21:45:07 +0200

The debian-archive-keyring is fixed for a while now, which means
'apt-key update' isn't called anymore by anything.

Problem (hopefully) solved and a whole release cycle to proof it.


Best regards

David Kalnischkies



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 25 07:24:25 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.