Comments on 1.0.6d

[David Shaw]

Hi,

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
   constantly:

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

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

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

-- 
   David Shaw  |  dshaw@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