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

Bug #1256565 reported by Lars Noodén
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Confirmed
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)

Revision history for this message
Lars Noodén (larsnooden) wrote :
Revision history for this message
Lars Noodén (larsnooden) wrote :

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

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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
Revision history for this message
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…]

Revision history for this message
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.

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.