small bugs and a small fix (1.4.1rc2 cvs)

Stephan Beyer s-beyer at gmx.net
Tue Feb 22 05:21:33 CET 2005


Hi,

after switching to 1.4.0 I noticed some smaller bugs which have not been
fixed yet.



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.

I took a look over the source and *thought* about possible solutions:
 a) In 1.4.0 the `sign_mode' variable is replaced by a preselected
    commands-list (first sign, then save). We could remove the "save"
    command, but that would lead to a very unintuitive usage: the user
    has to save and exit _manually_.
 b) Add the `sign_mode' variable (see 1.2.x) and everything would be
    as nice as in good old times again...
 c) Remove --sign-key at all and tell the user to use something like
     --edit-key uid N sign save
 d) Add a function which iterates over the user IDs and asks whether the
    user wants to sign it.

Well, I disliked a and c. And although d is less interactive than b, it's
more intuitive. So I wrote a small patch for the current HEAD cvs(1.4.1rc2),
downloadable at:
        http://noxa.de/~sbeyer/tmp/gnupg--sign-key.diff
        http://noxa.de/~sbeyer/tmp/gnupg--sign-key.diff.sig
( cd gnupgsourcedir && patch -p1 < ../gnupg--sign-key.diff )

What do you think about it?
The patch introduces choose_uids() in keyedit.c. I disliked the `keyword'
stuff, because I do not really know what it is used for, so I didn't test,
whether I implemented it in a useful way.



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.



not real bugs:

3) --delete-key name(s)

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

Then I took a look into the source / used the gdb debugger and was shocked,
because do_delete_key() in delkey.c and list_one() in keylist.c are totally
different. :\ I did not really try to fix it, because I could always use a
name which produces an exact match (fingerprint) and so it isn't a real
problem.



4) Be patient!

My first experience with GnuPG 1.4.0 was this: nothing happens at all. So I
kept my ~/.gnupg directory minimal: minimal secring, minimal pubring, no
trustdb - and it worked! Soon I noticed that it's the trustdb, which makes
gpg apparently do nothing (and according to `top' doing nothing eats almost
100% CPU). Of course, the same procedure as before: a look into the source
and I saw that it really does something.
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 ;)


Well, sorry for bad English. The only thing I did in the last 3 days was
sleeping, eating and scrolling over GnuPG source code ;) I hope it wasn't
worthless.

best regards,
Stephan Beyer

-- 
Stephan Beyer, 0xFCC5040F

Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail



More information about the Gnupg-devel mailing list