Bug#558784: Request for wheezy-ignore for Bug#558784 apt: re-adds removed keys
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Request for wheezy-ignore for Bug#558784 apt: re-adds removed keys
Processing control commands: tags -1 + wheezy-ignore Bug #558784 [apt] apt: re-adds removed keys Added tag(s) wheezy-ignore. -- 558784: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558784 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: Request for wheezy-ignore for Bug#558784 apt: re-adds removed keys
This bug has been already tagges as squeezy-ignore... and there seems to not be enough interest in fixig it
Bug#558784: apt: re-adds removed keys
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
]] 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
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). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
]] 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
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) ftpmas...@debian.org pub 1024D/ADB11277 2006-09-17 uid Etch Stable Release Key debian-rele...@lists.debian.org [...] shashlik# apt-key remove ADB11277 OK shashlik# apt-key update gpg: key 6070D3A1: Debian Archive Automatic Signing Key (4.0/etch) ftpmas...@debian.org not changed gpg: key ADB11277: public key Etch Stable Release Key debian-rele...@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-rele...@lists.debian.org not changed gpg: key 55BE302B: Debian Archive Automatic Signing Key (5.0/lenny) ftpmas...@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-rele...@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/. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#558784: apt: re-adds removed keys
Processing commands for cont...@bugs.debian.org:
reopen 558784
Bug #558784 {Done: David Kalnischkies kalnischkies+deb...@gmail.com} [apt]
apt: re-adds removed keys
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558784: apt: re-adds removed keys
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) ftpmas...@debian.org pub 1024D/ADB11277 2006-09-17 uid Etch Stable Release Key debian-rele...@lists.debian.org [...] shashlik# apt-key remove ADB11277 OK shashlik# apt-key update gpg: key 6070D3A1: Debian Archive Automatic Signing Key (4.0/etch) ftpmas...@debian.org not changed gpg: key ADB11277: public key Etch Stable Release Key debian-rele...@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-rele...@lists.debian.org not changed gpg: key 55BE302B: Debian Archive Automatic Signing Key (5.0/lenny) ftpmas...@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-rele...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
