small bugs and a small fix (1.4.1rc2 cvs)

[David Shaw]

On Tue, Feb 22, 2005 at 05:21:33AM +0100, Stephan Beyer wrote:

> 1) --sign-key
> 
> When signing a key with --sign-key, gpg asks `Really sign all user IDs?
> (y/N)'. Type `n' and 1.4.0 prints the hint to select the uids, but
> interprets `n' as a `No, I don't want to sign the key at all.' and exits.
> 1.2.x `returns' to the --edit-key-Command-prompt instead.

This is actually a feature.  The 1.2.x behavior is a little odd since
the user started from the command line, issued a command line command,
and then suddenly found themselves inside the --edit-key menu.  I
agree the hint is not useful and confusing when the user gets there
via --sign-key, so I will remove it for --sign-key.

Still, I rather like the general idea of an interactive walk through
each user ID.  I'll pick this up again for 1.4.2.

> 2) --keyserver x-hkp://keyserver.kjsl.com:80 --search-key xxx
> 
> This (see keyserver above) is the only patched PKS keyserver I know, which
> is running on port 80. That means, I can (and do) use it behind a firewall
> that dislikes accessing, for example, SKS servers on port 11371.
> --search on this server was no problem until I upgraded to GnuPG 1.4.0.
> 
> `Funny' is, that I tried to fix the problem, but got banned from the
> keyserver after some trial&error. I mailed Jason Harris (the owner?) and
> explained what happened, but haven't got a reply yet.

The problem is that keyserver.kjsl.com returns an odd response when
accessed over port 80 intead of 11371.  Instead of just giving the
answer, it gives three blank lines and then the answer.  This breaks
GnuPG's parser.  Jason - what's the deal here?  Can you easily remove
the blank lines?

Anyway, there is always pgp.srv.ualberta.ca on port 80.  It's SKS, and
supports multiple subkeys, photo IDs, etc.

> If <name> is matching on more than one key, I am only asked if the first
> match should really be deleted. First, I didn't understand the `bug',
> because I thought gpg behaves in another way:
>  1. it expands the names list to all possible matches, removes duplicates,
> etc
>  2. it processes (--delete-key, --list-key) the expanded list, item by item
> This means, I thought that --delete-key and --list-key work in an
> equivalent way, except that the last operation is different (delete or
> list)...

It's not clear what the right thing to do here is.  For example,
--sign-key or --edit-key works like --delete-keys: it stops after the
first match.  It's certainly different than --list-keys, but they have
different uses.

At one point I considered a --delete-key that had the current behavior
(first match), and a --delete-keys (with the 's') that acted like
--list-keys (all matches), but I was afraid that would be confusing.

> keyring.c's keyring_rebuild_cache was the bad guy. I first thought that it
> loops infinitely on my 14MB pubring (or 6MB pubring on another machine) -
> maybe it generates a `ring list' and then iterates over it. But my first
> thoughts weren't true. It's a usual loop, just a bit inefficient. So I
> started gpg --check-trustdb and it finished after 19 minutes. Since then,
> it came always to a fast end, luckily.
> 
> Why do I tell you that? It annoyed me... I thought that GnuPG 1.4. was
> broken and I was the only one noticing that. Maybe it should tell the
> people, that it rebuilds the cache / checks the trustdb and that this could
> take a while... It does, but not outside the source ;)

You're right.  I'll add a release note about this.  As you noted, it
is only slow the first time, since after that the cache already
exists.  I'm actually a little surprised that someone didn't have a
large cache built as the cache started being used in 1.0.7.

David