apt-key del gives wrong message if key is not in keyring

Bug #1256565 reported by Lars Noodén on 2013-11-30
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Undecided
Unassigned

Bug Description

If an attempt is made to remove a key that is already not on the list of trusted keys, apt-key gives no indication that the key
was not found. Instead it says "OK" no matter what:

 # apt-key del 40976EAF437BBBBB
 OK
 # apt-key list | grep 40976EAF437BBBBB
 # apt-key list | grep 40
 pub 4096R/C0B21F32 2012-05-11
 pub 4096R/EFE21092 2012-05-11
 # apt-key del 40976EAF437BBBBB
 OK

What should happen when an attempt is made to delete a key that is not found among the list of trusted keys is that apt-key should complain with some other message than "OK". Maybe a "Key not found" message would be appropriate.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apt 0.9.13~exp1ubuntu2
ProcVersionSignature: Ubuntu 3.12.0-3.8-generic 3.12.0
Uname: Linux 3.12.0-3-generic x86_64
ApportVersion: 2.12.7-0ubuntu1
Architecture: amd64
CurrentDesktop: LXDE
Date: Sat Nov 30 22:18:39 2013
InstallationDate: Installed on 2013-11-19 (11 days ago)
InstallationMedia: Lubuntu 14.04 "Trusty Tahr" - Alpha amd64+mac (20131118)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)

Lars Noodén (larsnooden) wrote :
Lars Noodén (larsnooden) wrote :

This patch shows where the error message is needed, but does not quite fix the unnecessary "OK" message

The attachment "partial fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
David Kalnischkies (donkult) wrote :

If we have an error message, the exit code should be non-zero, but we can't do this without surprising users (read: scripts).

While it might not be perfect, it is at least not wrong as 'del' does in this situation what it is supposed to do: remove the key from the keyring. This is a trivial task of course if the key isn't present before, but so it be: After the request the key is (still) removed.

Are you needing this for anything or was it just "surprising the first time round"?

Note btw that the remove_key_from_keyring function is called multiple times with different keyrings as keys can (not) be in different keyrings nowadays which all need to be inspected, so apt-key would have to keep track of how often it has nuked a key from a keyring so far adding lots of code for the small gain of printing an error message telling me that I wasted precious lifetime typing a command which boiled down to being a no-operation (and wasted another bunch of seconds on reading the error message).

[Bad enough that it prints "OK". It should really be silent…]

Lars Noodén (larsnooden) wrote :

This was more a case of worked other than expected. Since it provided feedback ("OK") I had expected that it would also say about the key's presence. So maybe the script is better silent. I have been using it manually and not in another script and usually have followed up with "apt-key list" to verify that "del" ran as expected. It's not a big deal and happens only a few times per year.

An error message with a non-zero exit status would be more what I would expect from the script if it can't find the key. But it sounds like doing that properly is not trivial.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers