Latest patches

[David Shaw]

I took some time recently to update and bring all the various patches
and bits of code I have for GnuPG up to the latest CVS version.  Here
they are in case anyone wants to play with them:

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.eyesonly.1

  Adds support for the "for your eyes only" flag.  This will cause PGP
  to pop up the "secure viewer" with the Tempest-resistant font, and
  GnuPG to refuse to save the data unless you specify --output
  specifically.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.keyserver.3

  Adds a generic keyserver interface, including support for LDAP and
  email keyservers.  Adds --search-keys to search a keyserver for a
  key.  Note that --search-keys *does* work with the HKP/HTTP
  keyservers.

  Thanks to Stefan Bellon for testing this well :)

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.lsigpromote.1

  If a user tries to sign a user ID that was already signed locally
  (i.e. a non-exportable signature), GnuPG will offer to promote the
  signature to full exportable status.  This is really just a user
  friendly way of doing "delsig" and then re-signing the user ID.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.nosignrevoke.1

  Does not allow the user to sign a revoked user ID or key unless
  --expert is set, and even then it prompts to make sure.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.pgp2.4

  This was originally intended as a quick way to set the options for
  PGP2 compatibility ("--rfc1991 --cipher-algo idea --compress-algo 1
  --digest-algo md5"), but now is more of a "Be PGP2-compatible or die
  trying".  It prevents the user from creating a message that would
  cause PGP2 to break.  I'm not quite content with this patch yet.  It
  feels like it needs more cooking.  Maybe a warning is better than
  prevention here.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.photoid.1

  Photo ID support, a la PGP.  This is implemented as generic
  attribute packet support, so we can add more attributes in the
  future (currently, the only defined attribute is "image", just like
  PGP).  Adds a --show-photo command line option, as well as
  "showphoto" and "addphoto" to the --edit menu.

  Bugfix so that users can sign photo IDs correctly.

  There are full instructions in options.skel

  This needs some cooking as well.  In particular, this could share
  quite a bit of the code in the keyserver patch.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.showpref.3

  Allow the user to select no compression via "--compress-algo 0" on
  the command line.  This fits with the OpenPGP algo 0, which also
  means no compression.

  Show compression preferences along with cipher and hash algorithms
  in the "showpref" listing.

  Permit setting a no-compression ("Z0") preference.

  Minor bugfix to fix a bug that corrupts the preference list.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.sigclass.2

  Force a v4 sig if the user has a notation or policy URL set.  This
  is for the same reason as the local sig forcing a v4 sig -
  otherwise, the sig might be v3 and thus silently drop the notation
  and/or policy.

  Ask the user how carefully they checked a key and user ID before
  signing it.  This is encoded into the signature class.

  Show flags in signature listings to show the check level of the sig,
  whether the sig is local, revocable, has a policy URL or notation,
  or has expired.

  New options show-notation, no-show-notation, default-check-level,
  no-default-check-level, show-policy-url, and no-show-policy-url.
  The notation and policy-url stuff turns on/off showing notations and
  policy urls in --list-sigs/--check-sigs.  The default-check-level is
  the default for the "how carefully did you check this key?"
  question.

http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6c.dms.sigexpire.1

  If you are signing a key that has an expiration date set, GnuPG will
  prompt to see if you want your signature to expire at the same time.
  This is to address the situation where the key is compromised and
  has its expiration date extended or removed.

  GnuPG will not allow you to sign a key that has expired unless
  --expert is set, and even then it prompts to make sure.

  Fills in the previously blank sig expiration field in --with-colons.

  Finally, if you have --expert set, you can select any expiration
  date you want for a signature.

  Sigs with an expiration date are marked critical - any OpenPGP
  implementation that does not understand expiring sigs should
  disregard these sigs altogether.  The rationale for this is that
  without the critical flag, an implementation that does not
  understand expiring sigs will treat these sigs as not expiring at
  all.  It is better for there to be no sig then for a sig to live
  longer than the user intended it to.  I'd be glad to hear other
  thoughts on this decision.

  All that said, some implementations may still treat expiring sigs as
  non-expiring.  Hopefully that will be treated as a bug and fixed.

  This patch does not do the --status stuff.  I don't use --status
  myself, so don't have any good way to test it.  If someone would
  like to help me out with this, let me know.

There is a little bit of common code between the patches - just enough
to smooth things over.  Patch should be smart enough to handle that
just fine.  On the other hand, many of the patches touch the key
signing code in keyedit.c, so it's unlikely you can apply them all
without resolving a few conflicts.

David

-- 
   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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 493 bytes
Desc: not available
Url : /pipermail/attachments/20011205/840d7e77/attachment.bin