1. xemacs
  2. mailcrypt


mailcrypt / README.gpg

MailCrypt for the Gnu Privacy Guard (GPG)
 -Brian Warner <warner@lothar.com>

The GPG support in mailcrypt is at an alpha level and is at least ready for
adventurous users to try out. There are a number of known problems, listed
below. Please send any and all comments, bug reports, patches, enhancements,
etc, to me at <warner@lothar.com>.

First off, what is GPG? GnuPG (formerly known as "g10") is a GPL'ed
replacement for PGP that implements the OpenPGP standard that is slowly making
its way through the IETF OpenPGP working group (it may well be a Proposed
Standard by now.. check your local RFC mirror). It does not implement any
algorithms that cannot be provided under the GPL; that means no RSA
(patented/licensed) or IDEA, so in general it does not interoperate with pgp
2.6 . However it should work with pgp 5.0, pgp 6.0 (theoretically), and of
course itself, and it has a shared-object-loading plugin mechanism whereby new
algorithms can be loaded, so of all the pgpgpgish programs out there it has
the best chance of being compatible. GPG is being developed entirely outside
the USA because of that silly ITAR nonsense.

The GPG home page is at <http://www.gnupg.org/>. The mailcrypt support for it
(contained mostly in mc-gpg.el) is mostly thoroughly tested against GPG
version 1.0.6, so you should use that version or a later one. However, it
ought to work fairly well with version 0.9.3 or later.


 key fetching:
  There is no key fetching. I don't know of any GPG keyservers yet. When some
  become available, I'll add support for them. If you try to verify the
  signature on a message when you don't have the signator's key, the code will
  offer to fetch the key for you. If you answer "yes, please fetch that key",
  you'll just get an error message.

 the --throw-keyid encryption option is not yet supported (a.k.a. "stealth
 mode", where the recipients' keyids are not included in the message, and the
 potential receiver must simply try all of their secret keys to see if any of
 them works).

 multiple recipients:
  not a problem with gpg 0.4.3 or later. In --batch mode, older versions did
  not properly decrypt messages that were encrypted to multiple recipients,
  including messages encrypted with the "mc-encrypt-for-me" option. If you
  can't use a newer version of gpg for decryption, you need to have your
  correspondents to send you messages that are only encrypted to you.

 wrapper script
  not a problem with gpg 0.4.1 or later. Older versions don't handle the
  "--passphrase-fd 0" option correctly, and need a wrapper script called
  "gpgwrap.pl". If you can't run a newer version of gpg, get the wrapper
  script from mailcrypt-3.5b7.


  You want to be confident that the keys you encrypt messages to are actually
  owned by the person named in the key, and not just some random goofball who
  likes to create and distribute keys with other people's names on them. Think
  about how you obtained someone's key: did they give it to you in person?
  Then it's probably the right one. Did they mail it to you? Did you get it
  by fingering their account? Chances are good that it's valid. Did it come
  from a keyserver? Anyone could have put it there. Suppose it's signed by
  someone that you trust to check the key's validity. Should you trust it

  This is the PGP (and GPG) "web of trust", and for more details you should
  check the pgp 2.6 documentation. Here's what mailcrypt-gpg does with trust:

   encryption: pass --always-trust in, forcing all keys to be trusted even
               if you don't have a trust path. This is necessary because
               without it, untrusted keys are just dropped, and your message
               won't be readable by all the folks you addressed it to.
   decryption: report the trust value in the echo area when checking a 
               signature. TRUST_ULTIMATE means the message is signed by one of
               your own keys. TRUST_FULLY and TRUST_MARGINAL are for keys that
               you trust via some path that starts with a key that you have
               signed with one of your private keys. For each public key in
               your keyring, you can specify (with --edit-key) how much you
               trust that key to sign other keys. The sum of these trust
               values along the path from your private key to the signator's
               key determines the amount of "owner trust" you have in that key
               and determines the TRUST_ value displayed when checking a
               signature. TRUST_UNDEFINED means that you do not have a trust
               path to that key.
   verify:     same as decryption

  Ideally, if you try to encrypt to an untrusted key, mailcrypt should give
  you a warning. A future version may do this.

 key names are passed through the shell enclosed in ""s. If the names have any
 quotes in them or seriously weird characters ("!" comes to mind) then the
 shell may have problems. I think the GPG key-generation process may restrict
 the key names to something reasonable, but other programs (pgp5.0?) might

 there is some debugging code left around. Some temporary buffers may get
 created but not deleted (names generally start with " *mailcrypt"). Some
 temporary files (/tmp/mailcrypt-gpg-*) may get left around.

 mc-gpg.el depends upon /bin/sh to run GPG while redirecting several file
 descriptors to temp files (to collect three different output streams). If you
 don't have /bin/sh, it probably won't work.

 I probably don't have enough (save-excursion ) and (unwind-protect ) clauses.
 If you run into an error halfway through an operation, or if you hit C-g and
 abort an operation, you might not be put back in the buffer you started with.
 Just find your original buffer and hit "undo" if necessary. All mailcrypt
 operations can be undone with "undo".

 I've tested a number of cases, but I haven't been able to create test
 messages for some of them, like signed messages that have been tampered with.
 (clearsigned messages with tampering are caught, but I don't know how to
 modify an unclear signed message to invalidate the signature without also
 damaging the CRC added by the ascii armor). If you know how to create such a
 message, please send it to me so I can test those cases too. The same goes
 for the (probably much more difficult) case of encrypted+signed messages that
 decrypt OK but have bad signatures.


 mc-gpg-comment works fine, I just disabled it to let GPG insert it's own

 mc-gpg-alternate-keyring might work. It should probably be split up so you
 can add public and private rings separately.

 mailcrypt is designed to handle multiple encryption schemes. Decryption is
 supposed to work by trying each one in order, stopping after one of them
 succeeds. mc-gpg.el will have two problems with this. One is that my code
 will probably error out upon failure instead of returning a failure and
 allowing the top-level scheme loop to try another scheme. The second is that
 pgp2.6, pgp5.0, and gpg all use the same packet format, so it isn't generally
 obvious what scheme should be used (unless you look for a version or comment
 header in the armored message). This is complicated by the fact that they can
 use each other's keys, to a certain extent. I don't have a good answer for
 this yet. One is to keep all your keyrings separate. One is to figure out how
 to use GPG for everything and merge all your keyrings into your GPG
 keyring. If you manage that one, let me know about it.


 it would be cool to incorporate some trust status reporting into this code.
 you give it a keyid and it shows you the best trust path to that key.

 key management from within emacs: sign keys, edit trust.

 set algorithm preferences or extra options (--rfc1991) by recipient ID. this
 might help pgp compatibility

 tab-completion on keyids, using --list-keys or --list-secret-keys.

 rfc2015 operation (MIME multipart/encrypted). see SEMI for the pgp version.

 create a detached signature from the current buffer

Share and Enjoy,
 -Brian Warner