Comments on 1.0.6d
dshaw at jabberwocky.com
Mon Mar 4 23:55:01 CET 2002
As promised, here's are some comments about the latest snapshot.
These are the "doesn't work right" comments. I'll do the "would be
nice" list later :)
I've started on fixes for #5, #8, #10, #13, and #15.
1) --edit a public key you have the secret key for, and use "adduid".
Make up any user ID you like, but when prompted for a passphrase,
just hit enter a few times. This causes an assertion failure:
"free-packet.c:287: free_user_id: Assertion `uid->ref > 0' failed."
2) The RPM spec file in scripts/gnupg.spec(.in) needs updating for the
keyserver helpers (gpgkeys_ldap, gpgkeys_mailto).
3) If a key is revoked, it is not shown as revoked in the --edit menu
until ownertrust is set for that key. This happens with expired
keys as well.
4) The 'keyid!' (with exclamation point) syntax works with public
(i.e. for encryption), but does not work with private (for signing)
keys. This seems to be because lookup() in getkey.c calls itself
and the flags are wiped.
5) When revoking a local key signature (i.e. from 'lsign'), the
revocation should be local as well to prevent possibly leaking
information about the local signature.
6) --list-packets shows an awful lot more than it used to in 1.0.6.
For example, when decrypting a message it shows the packets in the
keyring as they are read to find the key to decrypt with. This
makes it a lot less useful than it used to be. 1.0.6 used to only
show the immediate object being worked with - when decrypting for
example, it showed only the packets in the encrypted message.
7) When you delete a key with ownertrust set it does not disappear
from the trustdb. I mentioned this one a few months ago and I
think it was concluded to be a feature and not a bug, though I
still think that if I delete a key there should be no remnants of
that key left behind. The more significant problem is if there is
an ultimately trusted key that gets deleted, then gpg will complain
gpg: Oops: keyid_from_fingerprint: no pubkey
and whenever --update-trustdb or --check-trustdb is run:
gpg: public key of ultimately trusted key 00000000 not found
8) V3 key revocations should not prompt for a revocation reason since
V3 revocations do not use it anyway.
9) For some reason --with-colons no longer shows anything in the
10) The keyserver stuff needs an "exec-path" or similar, as the user's
path may be untrustworthy, and it is also difficult to use the
keyserver stuff via cron or other non-login methods without it.
11) --list-packets does not work with partial body lengths
12) Should "RIJNDAEL" be called "AES" now that the standard (at least
the US standard) went through? PGP calls it "AES", so there may
be confusion there. Perhaps GnuPG should accept both names?
13) The command "gpg --export 0xz blah" causes BUG() to be called.
14) Sign a key so that it's trust goes to "full". Now, delete or
revoke the signature. The trust level stays at "full" until you
export, delete, and then re-import the trustdb.
15) Compiler warning in util/:
iobuf.c:1891: warning: static declaration for `fseeko' follows non-static
(I'm not mentioning the compiler warnings in g10/keyedit.c as that
is the fault of the compiler and not the code.)
16) Assembler warning in mpi/:
_mpih-rshift.s:129: Warning: using `%dl' instead of `%edx' due to `b' suffix
17) Something seems to be not correct with MDC packets. Encrypt a
message so that MDC packets are included, and then run gpg on the
message. Do not enter a passphrase, but just hit enter a few
times. You get errors that seem to imply the message goes on
longer than gpg expects it to. This is visible with
--list-packets as well.
18) Using several config options like "default-recipient" or
"secret-keyring" in a config file with no argument causes a
19) If the user makes a key ultimately trusted, there is no way to
later make it not ultimately trusted without deleting the trustdb
or exporting the trustdb, editing it manually and re-importing it.
20) This isn't a problem, but I just wanted to comment on it in case
someone disagrees. In the way I wrote the signature expiration
and non-revocability code, expiration subpackets are marked
critical, and non-revocable subpackets are not.
The rationale for the non-revocable subpacket being not critical
is that the worst thing that could happen with such a signature is
that it ended up on an implementation that treated it as
revocable. Since the user is the only person who could issue the
revocation anyway, there is no problem here.
The expiration subpacket on the other hand, *is* marked as
critical, as if it was used on an implementation that did not
understand expiring signatures the signature could live longer
then the signer intended, which is clearly wrong. Better in that
case to have no signature rather than a signature that persisted
beyond when the user intended.
David Shaw | dshaw at jabberwocky.com | WWW http://www.jabberwocky.com/
"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence." - Jeremy S. Anderson
More information about the Gnupg-devel