apt-key says deprecated, but not saying what else to use

[Marco Möller]

Hello,
Command apt-key and its man page say that apt-key is deprecated, but do
not suggest an instead recommended tool. It is only mentioned that keys
would now be organized in /etc/apt/trusted.gpg.d/ . But how should I
manage the keys saved there, for instance how to update them, or what
tool of the Debian distribution is managing them there for the apt
functionality of the Debian OS?
Guiding me to a properly up-to-date documentation about this topic would
be welcome!
Marco.

[Andrei POPESCU]

Package: release-notes
X-Debbugs-Cc: debia...@lists.debian.org, a...@packages.debian.org

On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
>
> Command apt-key and its man page say that apt-key is deprecated, but do not
> suggest an instead recommended tool. It is only mentioned that keys would
> now be organized in /etc/apt/trusted.gpg.d/ . But how should I manage the
> keys saved there, for instance how to update them, or what tool of the
> Debian distribution is managing them there for the apt functionality of the
> Debian OS?

As far as I understand it's as simple as dropping the keys in there.

When a key changes/expires/etc. replace it with the new one (if provided
by the respective repository).

> Guiding me to a properly up-to-date documentation about this topic would be
> welcome!

Indeed the documentation on this is a bit scarce, probably worth a
mention in the Release Notes.

Dear APT maintainers,

The short version appears to be this note to the 'add' command from
apt-key(8):

Note: Instead of using this command a keyring should be placed
directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive
name and either "gpg" or "asc" as file extension.

where .gpg files are of type created with 'gpg --export' and .asc with
'gpg --armor --export'.


Your confirmation (or even better, proposes wording) would be much
appreciated.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Darac Marjal]

For some time, I've been using /etc/apt/trusted.gpg.d rather than using
apt-key. As I understand it, keys in apt-key are trusted to sign *any*
repository you pull from. That is, if you add a suspicious repository
and somehow they were able to push packages signed with their key to the
main debian repo servers, then you'd not be able to distinguish between
"signed by Debian" and "signed by attacker".

Instead, the preferred method is to put binary GPG keys into
/etc/apt/trusted.gpg.d (that is, you might need to run "gpg --dearmor"
if you download an ascii-armoured key). Files there can have any name
it's purely up to the system administrator what the names are, but it
makes sense that they indicate the repository they sign. Then, in
/etc/apt/sources.list.d/*.list, you need to write:

deb [signed-by=/etc/apt/trusted.gpg.d/somekey.gpg]
https://repo.attacker.com/ stable main

Now, only this repository trusts that key. If packages there are signed
by another key, verification fails. Similarly, if packages in another
repository are signed by that key, verification fails.

You ask about updating them. There is, as far as I know, no automatic
method for updating these keys, nor for automatically adding them right
now. That's because it's generally considered good practice to add the
key manually. You need to actively state that you trust this repository
on your system. So, for most repositories, that involves a web page
somewhere that says "This is our 'deb ... ' line and this is a link to
our public key." The key will usually be valid for several years, but if
it does start to fail, apt tools *will* tell you that the key has
expired, and that's time to go back and revisit the original site, and
see if they have a new key available.

[Gene Heskett]

I'd like to pleaed for a new apt-key, one that would survey the existing
list, and on finding a key that is expired or is no longer associated,
offer the option of removing it, or refreshiing it.

I have up to 7 machines on my local network, usually accessed by some
ssh/sshfs variation, but my current keyring since I'm first user,
probably has 30 some keys, many of which are useless as the target
machine has been changed by a new machine and a new bare metal install.

I consider those "dead" keys to be security risks. But at present, there
is not a means to identify and remove them that I am aware of.

So I would plead for an apt-key replacement that would automate that
process. At the present state, my connection scripts to re-establlish my
local network after a reboot or power failure recovery, are all blocked
because of machine replacements/reinstalls using the same ip address
yadda yadda, so I must answer yes, then supply my first user password
for that machine because I do want to continue connecting to that
machine. That can rapidly turn into a PITA.

Thanks for this thread.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Dan Ritter]

Gene Heskett wrote:
> I'd like to pleaed for a new apt-key, one that would survey the existing
> list, and on finding a key that is expired or is no longer associated,
> offer the option of removing it, or refreshiing it.
>
> I have up to 7 machines on my local network, usually accessed by some
> ssh/sshfs variation, but my current keyring since I'm first user,
> probably has 30 some keys, many of which are useless as the target
> machine has been changed by a new machine and a new bare metal install.

This is ssh key management, not apt key management. apt key
things are for trusting package repositories.

> I consider those "dead" keys to be security risks. But at present, there
> is not a means to identify and remove them that I am aware of.
>
> So I would plead for an apt-key replacement that would automate that
> process. At the present state, my connection scripts to re-establlish my
> local network after a reboot or power failure recovery, are all blocked
> because of machine replacements/reinstalls using the same ip address
> yadda yadda, so I must answer yes, then supply my first user password
> for that machine because I do want to continue connecting to that
> machine. That can rapidly turn into a PITA.

Here's what you should do:

1. create a new ssh keypair on your main machine:
ssh-keygen -t rsa -b 4096 -f gene2021

2. for each $targetmachine in your 7 machines, do this:
- ssh $targetmachine
- mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old
- don't close that terminal
- open a new terminal and make sure you can ssh in by
password, then
- ssh-copy-id gene2021 $targetmachine
- make sure you can ssh in with the gene2021 key:
ssh -i gene2021 $targetmachine
- if it's good, close both terminals and go on to the next
$targetmachine

3. clean up: remove keys in ~/.ssh/ that aren't gene2021 and
aren't useful otherwise.

Now you have one known good keypair that lets you in to all
seven machines without a password, and you can use a password as
fallback.

Now, it sounds like you also have a problem with machines
getting randomly assigned IP addresses. In a network of size 7,
I would strongly advise you to stop using DHCP and just put in
static IP assignments for each machine in
/etc/network/interfaces.

-dsr-

[Charles Curley]

On Sun, 20 Jun 2021 10:21:52 -0400
Dan Ritter <d...@randomstring.org> wrote:

> Now, it sounds like you also have a problem with machines
> getting randomly assigned IP addresses. In a network of size 7,
> I would strongly advise you to stop using DHCP and just put in
> static IP assignments for each machine in
> /etc/network/interfaces.

That certainly will work. Since Gene already has dhcp up and running,
he can also use it to assign fixed ip addresses, e.g.:

host orca # Lenovo T61
{
option host-name "orca";
hardware ethernet 00:13:8E:BA:7E:59;
fixed-address 192.168.101.18;
ddns-hostname orca;
}


--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[Gene Heskett]

I haven't used dhcp in 23 years, don't even run a server in my dd-wrt
router. Used a hosts file on my first install in 1998, never saw an
advantage to changing.

Sometimes a new machine gets added while the old one is still live and
eventually gets renamed/readdressed when the old one has supplied its
data to the new one and is turned off for good, but those keys remain.

Case in point, demoing side effects, I had a pair of ark shoeboxes
running cnc machines in the garage and they started to fail a year ago
so I bought 4 off-lease dell 7010's with 4 core i5's and 4 gigs of ram
as thats a great plenty to run LinuxCNC. No drives, no winders licence.
Cheap that way.

The old ark's with d525mw mobos were so noisy I had to be within 10 feet
of the garage door motor to run it with a pocket pad. After replacing
the old arks with the dells, all with SSD's now, I found my pocket pad
could run it from 80+ feet away. The Dells were that much quieter. But
they run 24/7 and I am seeing a rise in my electric bill from all those
old i5's. But one got dedicated to running a 3d printer so got its dram
filled up and its been shut down and rebooted a couple hundred times
since with no problems in its SDD so I may start shutting them down but
then when do I turn amanda loose to back them up? She doesn't like her
schedule to be disturbed.

If I live long enough, I'm 86 now, I may convert them all to being run
with rpi4's. Draws about 25 watts with its monitor, but runs a 4kw
machine when LinuxCNC is running as the machines power is 100%
controlled by LinuxCNC. And the rpi4 has more than enough giddyup to run
LinuxCNC well. An rpi3 can do it too, but its being pushed. Part of that
holdup is the cost of the interfacing to the pi's, over $200 a copy. 4
mesa cards involved per copy.

Thanks for the instructs Dan, recipe printed, I'll see about doing the
cleanup one machine at a time.

[Brad Rogers]

On Sat, 19 Jun 2021 22:07:35 +0200
Marco Möller <ta...@debianlists.mobilxpress.net> wrote:

Hello Marco,

>Command apt-key and its man page say that apt-key is deprecated, but do

Coincidentally, I recently got notification of a pertinent blog post by
Julian Andres Klode. See;
https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/

I'm sure it'll prove useful to you. It expands on (some of) what's
already been said in this thread.

--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
My body's an oasis to drink from as you please
Mirage - Siouxsie & The Banshees

[Gene Heskett]

On Sunday 20 June 2021 10:21:52 Dan Ritter wrote:

> Gene Heskett wrote:
> > I'd like to pleaed for a new apt-key, one that would survey the
> > existing list, and on finding a key that is expired or is no longer
> > associated, offer the option of removing it, or refreshiing it.
> >
> > I have up to 7 machines on my local network, usually accessed by
> > some ssh/sshfs variation, but my current keyring since I'm first
> > user, probably has 30 some keys, many of which are useless as the
> > target machine has been changed by a new machine and a new bare
> > metal install.
>
> This is ssh key management, not apt key management. apt key
> things are for trusting package repositories.

okay, but

>
> Here's what you should do:
>
> 1. create a new ssh keypair on your main machine:
> ssh-keygen -t rsa -b 4096 -f gene2021

Done. generated /home/gene/gene2021 and /home/gene/gene2021.pub

> 2. for each $targetmachine in your 7 machines, do this:
> - ssh $targetmachine
> - mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old

4 of the 6 machines have no .ssh directory in /home/gene. ssh may have
had to be installed after the bare metal install of debian 10 using the
linuxcnc install cd. sshfs and its deps sure had to be after the first
reboot. I'll go bug the LinuxCNC install spinners, been meaning to do it
for months.

Is it sufficient to create that directory, and
touch .ssh/authorized_keys?

Also, the main machine, this one is still on stretch. With 310 gb used of
a 2T spinning rust drive as /. I have a 500 gb samsung SSD, but haven't
found a round-tuit cuz I'd probably wear out the SSD until I get at
least a 1T SSD I can afford. Thats getting closer though. But it will
not happen when I am in the middle of designing and building a new,
smaller harmonic drive for one of my cnc machines.

> - don't close that terminal
> - open a new terminal and make sure you can ssh in by
> password, then
> - ssh-copy-id gene2021 $targetmachine
> - make sure you can ssh in with the gene2021 key:
> ssh -i gene2021 $targetmachine
> - if it's good, close both terminals and go on to the next
> $targetmachine
>
> 3. clean up: remove keys in ~/.ssh/ that aren't gene2021 and
> aren't useful otherwise.
>
> Now you have one known good keypair that lets you in to all
> seven machines without a password, and you can use a password as
> fallback.
>

> -dsr-

[to...@tuxteam.de]

On Sun, Jun 20, 2021 at 12:57:10PM -0400, Gene Heskett wrote:

[...]

> Is it sufficient to create that directory, and
> touch .ssh/authorized_keys?

Creating the directory should be enough: ssh-copy-id will
take care of making (or overwriting) the file.

You'll want to make sure the SSH server package is installed:
openssh-server.

Cheers
- t

[Greg Wooledge]

On Sun, Jun 20, 2021 at 03:00:20PM -0400, Dan Ritter wrote:
> The directory can just be created, and then the perms need to be
>
> chmod 600 ~/.ssh

700, sir.

[Dan Ritter]

The directory can just be created, and then the perms need to be

chmod 600 ~/.ssh

authorized_keys will be created by ssh-copy-id.

> Also, the main machine, this one is still on stretch. With 310 gb used of

All of these commands work on stretch and later.

-dsr-

[Dan Ritter]

Thank you.

-dsr-

[Andrei POPESCU]

On Du, 20 iun 21, 10:20:42, Andrei POPESCU wrote:
> Package: release-notes
> X-Debbugs-Cc: debia...@lists.debian.org, a...@packages.debian.org
>
> On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> >
> > Command apt-key and its man page say that apt-key is deprecated, but do not
> > suggest an instead recommended tool. It is only mentioned that keys would
> > now be organized in /etc/apt/trusted.gpg.d/ . But how should I manage the
> > keys saved there, for instance how to update them, or what tool of the
> > Debian distribution is managing them there for the apt functionality of the
> > Debian OS?
>
> As far as I understand it's as simple as dropping the keys in there.
>
> When a key changes/expires/etc. replace it with the new one (if provided
> by the respective repository).
>
> > Guiding me to a properly up-to-date documentation about this topic would be
> > welcome!
>
> Indeed the documentation on this is a bit scarce, probably worth a
> mention in the Release Notes.

Which already exists, under "Deprecated components for bullseye".

[Jonathan Dowland]

On Sun, Jun 20, 2021 at 10:21:52AM -0400, Dan Ritter wrote:
>This is ssh key management, not apt key management. apt key
>things are for trusting package repositories.

...

>Here's what you should do:

Kindly change the Subject: when you change the subject.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jm...@debian.org
🔗 https://jmtd.net

[Marco Möller]

Thanks a lot, this is quite helpful information!

I now understand that these gpg keys in the /etc/apt/trusted.gpg.d/
sub-directory are managed by apt after simply having placed manually the
files there, each file containing a binary formatted key. These keys are
automatically trusted by apt and hence the "trusted.gpg.d" label for
that sub-directory. Keys at this location are not related to the openPGP
key management which as a user is usually done with the explicit use of
the gpg command. Because of apt internally managing these keys and these
keys not intended to become manipulated manually with the gpg command by
the system administrating user, the gpg command --refresh-keys cannot be
used as a replacement for the deprecated "apt-key update" command.
Please correct me if I would have got it wrong.
Thanks a lot! Marco.

[Marco Möller]

On 20.06.21 17:36, Brad Rogers wrote:
> On Sat, 19 Jun 2021 22:07:35 +0200
> Marco Möller <ta...@debianlists.mobilxpress.net> wrote:
>
> Hello Marco,
>
>> Command apt-key and its man page say that apt-key is deprecated, but do
>
> Coincidentally, I recently got notification of a pertinent blog post by
> Julian Andres Klode. See;
> https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/
>
> I'm sure it'll prove useful to you. It expands on (some of) what's
> already been said in this thread.
>

This indeed is a very helpful blog post!
Always feeling intimidated to bother you experts with my stupid
questions, I now found the topic also being picked by the German spoken
"linuxnews.de" site, where they updated a related older post from April
with the information from Klose's new blog post. Seems as if my question
was not so stupid but was touching a problem which more people found
worth to comment on.
Marco.

[Marco Möller]

Andrei, thanks for having picked up my problem and having cared for the
release notes to comment on it, and also for supposedly having motivated
Julian Andres Klose to publish a very helpful blog post on the related
subject. Brad Rogers here in the thread linked to it in his answer to
me, thanks also for this.
Darac Marjal in his answer made me understood, that my problem was NOT
about knowing how to copy a key file to a directory, but about being
convinced that it is allowed to simply copy files to the
/etc/apt/trusted.gpg.d/ sub-directory without having to manage this by a
special tool like gpg. For convincing me, maybe the man page of apt-key
was simply missing a word like "manually" for expressing to "manually
place files in this sub-director". As a beginner being confronted with
security relevant procedures, specially when it is about things like PGP
keys based on a Web Of Trust concept, you easily suspect that a special
security tool would exist for ensuring that handling the important
package signature key infrastructure is done correctly. Obviously not.
Simply copying a key there appears is really enough to get access to a
repository.

I stumbled over this problem with apt-key because I am learning to make
use of openPGP right now, therefore studying GnuPG and its gpg tool, and
by this approaching how I maybe could also make use of the package
signatures to review if my OS installation was manipulated in an
unauthorized way after by me requested package installations, only to
find that the tool apt-key mentioned in this context by the "Securing
Debian Manual" is deprecated already.
Obviously, being new to this topic, I was then not properly separating
the concept of gpg being a tool to manage openPGP keys, but the keys not
necessarily having to be tightly bound to the keyrings which as a user I
can manage with the gpg command. Insights about my apt-key related
findings derived from the answer of Darac Marjal, from the blog post of
Julian Andres Klose, and from many(!) other texts about openPGP and
GnuPG which I studied in the last days, I have summarized by the
following words in my answer to Darac Marjal. Maybe these words can also
serve for the documentation of the deprecation of the apt-key command
and for the documentation of the usage of the /etc/apt/trusted.gpg.d/
sub-directory? Here my words, hoping they are describing the situation
correctly:

--> " The gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are

managed by apt after simply having placed manually the files there, each
file containing a binary formatted key. These keys are automatically
trusted by apt and hence the "trusted.gpg.d" label for that
sub-directory. Keys at this location are not related to the openPGP key
management which as a user is usually done with the explicit use of the
gpg command. Because of apt internally managing these keys and these
keys not intended to become manipulated manually with the gpg command by
the system administrating user, the gpg command --refresh-keys cannot be

used as a replacement for the deprecated "apt-key update" command. " <--

It then might be recommended to also add something like the following to it:
" Although not needed for technical functionality, it is highly
recommended to confirm that a key indeed belongs to the package provider
before adding the binary key containing file to this sub-directory.
Further reading on the best practice of how to confirm this is provided
in .... " here needs to come a good link suggestion, which I do not
have right now.

I could imagine, that the link could point to Chapter 7.5 "Package
signing in Debian" of the "Securing Debian Manual" (
https://www.debian.org/doc/user-manuals#securing ) - after this chapter
would have been updated to the current situation, apt-key is obviously
deprecated, and adding maybe there a small advise on how to check a key
file for its signatures acting as the Web Of Trust.

Best regards, Marco.

[Andrei POPESCU]

Well, it makes perfect sense if you remember that "everything is a
file", even if there are exceptions (e.g. network devices).

Documentation for actions requiring specialized tools is rather of the
form "use foo to add an entry to baz", e.g. in the context of GnuPG it
would be "use gpg to add this public key to <keyring>" (which is also a
file, but must be manipulated with specialized tools).

> Here my words, hoping they are describing the situation correctly:
>
> --> " The gpg keys in the /etc/apt/trusted.gpg.d/ sub-directory are
> managed by apt after simply having placed manually the files there, each
> file containing a binary formatted key.

To me managing implies that apt is somehow able to add, remove and
possibly refresh them, which is exactly the issue you stumbled upon. In
my opinion a better wording would be:

The keys in the /etc/apt/trusted.gpg.d/ sub-directory are managed by
the system administrator, by copying the corresponding public key of
each repository in the directory as a separate file, either in gpg
binary format or ASCII armored format.

> These keys are automatically trusted
> by apt and hence the "trusted.gpg.d" label for that sub-directory.

Ok, with a minor nitpick: in my opinion it's better to use uppercase APT
when talking about the Advanced Package Tool and lowercase `apt` when
talking about the (not so new anymore) command-line tool.

Can't find a good reference for this at the moment.

> Keys at
> this location are not related to the openPGP key management which as a user
> is usually done with the explicit use of the gpg command. Because of apt
> internally managing these keys and these keys not intended to become
> manipulated manually with the gpg command by the system administrating user,
> the gpg command --refresh-keys cannot be used as a replacement for the
> deprecated "apt-key update" command. " <--

Do you still think this is needed after my rewording above?

> It then might be recommended to also add something like the following to it:
> " Although not needed for technical functionality, it is highly recommended
> to confirm that a key indeed belongs to the package provider before adding
> the binary key containing file to this sub-directory. Further reading on the
> best practice of how to confirm this is provided in .... " here needs to
> come a good link suggestion, which I do not have right now.

Yes, something like this would be a good idea in my opinion. Most
third-party repositories out there just provide some commands to be
executed with root privileges.

The steps are likely to involve using gpg to inspect the key and
signatures on it without actually importing it to the user's keyring.
Which incidentally could also be part of installing that key, if the
last step involves some version of 'gpg --export | sudo tee'.

However, this implies the key is actually published on GPG servers,
which might not always be the case. There is nothing stopping a
repository maintainer to generate a key, place it on some website for
others to download and use "to make APT happy", but never bother to get
signatures for it and publish the signed key on GPG servers.

> I could imagine, that the link could point to Chapter 7.5 "Package signing
> in Debian" of the "Securing Debian Manual" (
> https://www.debian.org/doc/user-manuals#securing ) - after this chapter
> would have been updated to the current situation, apt-key is obviously
> deprecated, and adding maybe there a small advise on how to check a key file
> for its signatures acting as the Web Of Trust.

Feel free to suggest patches for it through bugs against the harden-doc
package, or merge requests in Salsa if the Maintainer is accepting them.

[Marco Möller]

On 26.06.21 11:54, Andrei POPESCU wrote:
> (...)

Very good points, all appreciated.

> Feel free to suggest patches for it through bugs against the harden-doc
> package, or merge requests in Salsa if the Maintainer is accepting them.

I'll do so. I decided, motivated also by observing how you are doing it,
to become more active in this regard. :-)

Thanks a lot! Marco.

[Cindy Sue Causey]

Hopefully I'm reading this right. While on dialup, I spent A LOT of
time battling a well-known closed source modem tty* driver. Out of
desperation, I could sometimes get it to work by copying it between
hard drives that contained separate operating systems.

BUT you can't just e.g. "cp" or "right click > copy" it over. It would
fail with a "Can't copy special file" error message. I know this
because I just did it again with ttyS0. You CAN rsync it between
partitions, and it would be viable, usable.

> Documentation for actions requiring specialized tools is rather of the
> form "use foo to add an entry to baz", e.g. in the context of GnuPG it
> would be "use gpg to add this public key to <keyring>" (which is also a
> file, but must be manipulated with specialized tools).

Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[to...@tuxteam.de]

On Sat, Jun 26, 2021 at 08:42:26AM -0400, Cindy Sue Causey wrote:
> On 6/26/21, Andrei POPESCU <andreim...@gmail.com> wrote:

[...]

> > Well, it makes perfect sense if you remember that "everything is a
> > file", even if there are exceptions (e.g. network devices).
>
>
> Hopefully I'm reading this right. While on dialup, I spent A LOT of
> time battling a well-known closed source modem tty* driver. Out of
> desperation, I could sometimes get it to work by copying it between
> hard drives that contained separate operating systems.
>
> BUT you can't just e.g. "cp" or "right click > copy" it over. It would
> fail with a "Can't copy special file" error message. I know this
> because I just did it again with ttyS0. You CAN rsync it between
> partitions, and it would be viable, usable.

Wait a sec. You are not trying to copy /dev/ttyS0 (or its kin)?

Because that won't really make much sense. Or, well, it will perhaps
do surprising things.

See, /dev/ttyS0 is a representation of an external device (your first
serial interface, if your computer still has such a thing). You can
open it, read from it (which will yield incoming characters), write
to it (which will send the characters out, if all goes well) -- so
to your applications it presents an interface similar to the one
a file presents. This is Andrei's quote "everything is a file".

If you now copy /dev/ttyS0 to /tmp, e.g.

sudo cp /dev/ttyS0 /tmp

and assuming there's something connected to it and sending us characters,
there will be an ever-growing /tmp/ttyS0 and the copy will terminate
the moment the serial connection's other side "hangs up".

Now if you do

sudo cp -a /dev/ttyS0 /tmp

you get something completely different: a device file (referring to the
exact same device as your original).

Don't forget to remove them after: your system administrator might get
mighty confused finding a device file in /tmp :-)

Cheers
- t

[Nicholas Geovanis]

Perhaps it should be said that personal use of gpg and the use that a system administrator makes of it and key-ing are different use-cases. So we might expect fewer assumptions to hold and greater mystery :-)