On Wed, May 06, 2020 at 08:11:15AM +0000, Vipul wrote:
> I noticed, `apt-key remove` command always print "OK" output with
> incorrect fingerprint (keys which don't exist in keyring database). For
> curiosity, I run `sudo apt-key remove` (without providing any
> fingerprint) command, prints "OK" output on terminal. Is this expected
> behavior of apt-key remove?
First of all: Expected behaviour nowadays is that nobody is using
apt-key anymore. It is a bug if you do as we do not ensure that it
is in working condition (aka: gnupg{,2} is installed) and add/remove
functionality is a thousand times better done via cp/mv/rm in
/etc/apt/trusted.gpg.d/.
apt-key and especially the remove part is only there for you to clean up
from versions which did not support that directory yet [it is supported
for a literal decade(!) now…].
Yes, apt-key has some minor remaining usecases for the public like
listing the keys in the trust store and is important for our internal
use, but neither can really be used in scripts.
> $ sudo apt-key remove
> OK
In math you will not get an error if you exclude an element from a set
even if that element was never part of the set to begin with: You get
the result you asked for: A set without that element.
apt-key chooses to work the same way here. That helps in key transitions
I presume as you can in scripts blindly fire a 'remove oldkeyid' without
carefully checking if the key is present at all (which would require
locking and stuff as well…). It also simplifies apt-key code which
wanted to be a very simple gnupg wrapper [but grew into a not so simple
monstrosity to workaround various problems we have with gnupg] which has
the same behaviour.
You could question of course if no parameter is really something which
should be handled in this way, but it is what it is now and changing it
just means breaking it for everyone who depends on that behaviour [0] –
beside, as said above, nobody expect extreme legacy is supposed to use
it still.
[0] https://xkcd.com/1172/
> One more thing, I didn't find any mention of **remove** sub-command in
> apt-key's man page; but do seems like **del** and **remove** are same.
> Why is so?
Hidden aliases which exist since day one of that script apparently.
I suppose it is a way of "doing the right thing™" for a user while
documenting only a single one to have a clear interface for scripts.
Similar to how "apt dist-upgrade" works even through documented is only
"apt full-upgrade".
If this is a good or bad idea can be debated all day long.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature