Bug#558784: status of this bug?
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 KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#558784: status of this bug?
On Fri, Mar 2, 2012 at 16:35, Helmut Grohne 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558784: status of this bug?
]] 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558784: status of this bug?
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
