Control: tags -1 - jessie sid Control: found -1 0.9.10 # introduced by git commit 04937adc655ceda0b3367f540e76df10296cfba1 On Thu, Apr 09, 2015 at 01:30:19AM -0400, Nathan Kennedy wrote: > Tagging this as a security issue since the effect is to allow > installation of packages signed with keys that the administrator (or a > an administrative script) specifically intended to remove, and this is > a regression from wheezy. I think 'security' is a bit much here but well… The 'OK' was always the case, removed or not and changing this at this point in time is completely out of question as there might be maintainerscripts depending on this behavior (many -keyring packages remove 'old' keys or transition to fragment files and not all of them ignore the exitcode of apt-key in this case). Beahviour changes two seconds before release are no good. The regression on lower-case (aka the grep -i) is under consideration for jessie. A pre-approval unblock request with this (and other things) was filled yesterday (see #782131). Note that the output from gnupg as well as from apt is uppercase, so its likely that lowercase is only encountered if people interactively type out the keyids, which is not a very common usecase – after all apt-key is supposed to be used mainly by -keyring packages and even those are supposed to get away from using it leaving next to nobody with a valid usecase to use it… … expect apt itself in future. See the experimental branch which reworks apt-key to make what used to be considered the enemy (= the idea was to remove dependency on gnupg and ultimatively drop apt-key) our best friend (= future gnupg2 is going to enforce some new rules like only one keyring which work directly against e.g. trusted.gpg.d/ so we need gpg to do all sorts of clever magic instead of resorting to gpgv only :/ ). > Pull request with fix to sid is attached. This doesn't fully restore > previous behavior; before long keyids could be used as well, but it > allows mixed case and fails if deletion fails (LP 1256565). Please split up your patches into meaningful self-containt entities. Ignoring case is independent from erroring on not found for example, so that should be two commits, not bundled up in one. As said, the later isn't going to be considered for jessie, but we could do e.g. a warning for stretch and error for buster. Please report a new bug for this – if you want to adapt your patch all the better (please against /experimental aka soon-to-be stretch). btw: /experimental also restores fingerprint (long keyid is supported). What it doesn't is all the various other things of matching a key gnupg supports – if those happen to work (or not) is undefined by the manpage (it says only "keyid"). > +msgtest "Try to remove a" 'nonexistent keyid' > +testfailure --nomsg aptkey --fakeroot --keyring rootdir/etc/apt/trusted.gpg del BOGUSKEY Such a test is probably better of using a valid keyid – otherwise you are testing if bogus ids trigger an error, not if a nonexistent id triggers an error. > msgtest "Try to remove a key which exists, but isn't in the" 'forced keyring' > testsuccess --nomsg aptkey --fakeroot --keyring rootdir/etc/apt/trusted.gpg del DBAC8DAE Shouldn't (at least) this testcase fail if you fail on not acting? Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature