up a creek

[dan at geer.org]

Dear gnupg-users,

I was using gpg 1.4.1 on Mac OSX 10.3.9.  There
appears to be a UI bug: if you want to use the
"--edit-key" function and you have more than one key
with the same name, that the UI will only list and
only operate on the one of the list of multiple keys
with the same name.

Why would you have a key with the same name?  If you
choose (and I chose) to have expiring keys.  The only
key the UI will talk about is not the one I want to
talk about, and thus begins my problem.

I did discover that "--list-keys" allowed me to find 
the KEYID that I actually wanted, and, further, that
I could use the KEYID instead of the name as a value
for the "--edit-key" function.  What I then did was to
extend the life of the relevant key ("expire") by one
year.  Unfortunately, this seemed to get me into a
sort of half-state:

===============================================
% gpg --edit-key FDE5027B
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Secret key is available.

pub  1024D/67BFF798  created: 2006-01-20  expires: 2008-03-27  usage: CS
                     trust: ultimate      validity: ultimate
sub  2048g/FDE5027B  created: 2006-01-20  expired: 2007-01-20  usage: E
[ultimate] (1). Dan Geer <dan at geer.org>
===============================================

Note the different expire dates between keys in the
above.  I'm guessing that expiring keys is an infrequently
used part of the code base.

Now this led me to ask at macgpg.sourceforge.net if
I was correct.  There I got the advice to not use
1.4.1 but to download and build 1.4.7.  That was not
hard and not scary, though the front page instructions
do say that for binary downloads 1.4.7 is only for
Mac OSX 10.4.x, and the 1.4.1 was the latest binary
for 10.3.9.  Nevertheless, after confirming that a
build of 1.4.7 was appropriate for 10.3.9, I did as
suggested, and downloaded and built according to
directions, including getting passing grades on all
27 tests that are done with "make check -i".
Therefore, and consistent with the instructions, I
did "sudo make install". 

I then ran this as my very first instruction:

% gpg --list-key
gpg: fatal: can't create directory `/Users/geer/.gnupg': File exists
secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768

and, somewhat disastrously, I appear now to have no
keyfiles.  Consulting with the macgpg folks again,
they found the above hard to imagine; in particular
the error message indicated that a file exists in
my homedir named .gnupg; not a directory but a file.
While they found this odd and inexplicable, that
much at least was understandable: ~/.gnupg is and
was a symlink to a directory in an encrypted volume.

% ls -l ~/.gnupg 
lrwx------  1 geer ... /Users/geer/.gnupg@ -> /Volumes/private2/dg/.gnupg/

% ls -l /Volumes/private2/dg/.gnupg
ls: /Volumes/private2/dg/.gnupg: No such file or directory

In other words, it appears that the install process
or the first-run command to --list-keys destroyed
the contents in the encrypted volume, not the symlink
itself.  The macgpg folks found that situation to be
so unexpected that they said I should join this list
and ask about my situation here.

Yes, there is a backup on a token device that is hidden
in another location, so the keys are not really and
truly lost, but while they may not be lost I am surely
lost and ask to be found.

Advice?

--dan, first time poster