up a creek

[David Shaw]

You have quite a few questions here.  I'll answer them as they come up
inline.

On Tue, Apr 03, 2007 at 09:35:28PM -0400, dan at geer.org wrote:
> 
> 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.

Yes, this is a feature.  You can also use the key fingerprint here if
you like.

> 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.

No, this worked correctly.  An OpenPGP "key" is actually multiple keys
glued together.  Each of these keys has their own independent
expiration date, so if you want to change an expiration, you need to
specify which key (primary or subkey) you are changing the expiration
of.  In your case above, if you wanted to change the expiration of the
subkey, you'd type "key 1" before "expire".

The man page says:

   expire   Change the key expiration time. If a subkey is selected,
	    the expiration time of this subkey will be changed.  With
            no selection, the key expiration of the primary key is
            changed.

Incidentally, since the "identity" of a key is tied to the primary
key, it is a fairly common situation to have a primary key that does
not expire, but a subkey that does.  Then you can keep making subkeys,
and letting them expire over time without having to tinker with the
primary key.  A nice side effect from doing things this way is that
the primary key can even be kept offline altogether.

> 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.

That's the precompiled binary downloads distributed by the MacGPG
project.  If you're building it yourself, you can do it on whatever
OSX you have.  I personally test new releases on 10.3 and 10.4 (both
PPC and Intel).

> 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".

Don't use '-i'.  I'm not sure where that idea got started, but it's
just not correct.  -i tells make to keep going after a failure, and
that's not something you want to do: if there is a failure, best to
just stop.  (This is just a side comment - I doubt it has anything to
do with the problems you had later).

> 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

I see what happened, but I don't think installing the new GPG did this
to you.  You had a symlink to a directory, and something removed every
file in that directory, and then the directory itself, before GPG ran
as above.  Aside from calling keyservers, which creates and deletes
randomly named temporary directories like "/tmp/gpg-2iSFzk", GPG
simply doesn't have any code in it to delete directories:

$ find . -name '*.c' | xargs grep rmdir
./g10/exec.c:      if(rmdir(info->tempdir)==-1)

Are you using some front-end or installer that might have done this?
Did you delete your GnuPG 1.4.1 installation before adding the new
one?

David