# HG changeset patch # User markus schnalke # Date 1341952090 -7200 # Node ID 3d7db5c7965de830ce0fcaacfe1d2590d16ddb38 # Parent 25d05add0d9766eb356b1e83236cdeef810e9491 Finished the section on signing and encryption. diff -r 25d05add0d97 -r 3d7db5c7965d discussion.roff --- a/discussion.roff Tue Jul 10 18:48:32 2012 +0200 +++ b/discussion.roff Tue Jul 10 22:28:10 2012 +0200 @@ -2361,99 +2361,99 @@ .[ neil rickert mhsign mhpgp .] -were included into mmh. -The scripts fit well into the mmh, because they are lightweight and -of style similar to the existing tools. +were included into mmh +.Ci f45cdc98117a84f071759462c7ae212f4bc5ab2e +.Ci 58cf09aa36e9f7f352a127158bbf1c5678bc6ed8 . +The scripts fit well because they are lightweight and +similar of style to the existing tools. Additionally, no licensing difficulties appeared, as they are part of the public domain. .P -The scripts were written for nmh, hence I needed to adjust them according -to the differences of mmh. -For instance, I removed the use of the backup prefix and dropped support -for old PGP features. -.P .Pn mhsign handles the signing and encrypting part. It comprises about 250 lines of shell code and interfaces between .Pn gnupg and the MH system. -It was meant to be invoked at the WhatNow prompt, but in mmh, +It was meant to be invoked manually at the WhatNow prompt, but in mmh, .Pn send -does the job automatically. -Special header fields were introduced to request the action. +invokes +.pn mhsign +automatically +.Ci c7b5e1df086bcc37ff40163ee67571f076cf6683 . +Special header fields were introduced to request this action. If a draft contains the .Hd Sign header field, .Pn send -will sign it. -The key to be used is either chosen automatically or specified by the +will initiate the signing. +The signing key is either chosen automatically or specified by the .Pe Pgpkey profile entry. .Pn send -always signes messages using the PGP/MIME standard, \" REF XXX +always create signatures using the PGP/MIME standard, \" REF XXX but by manually invoking .Pn mhsign , old-style non-MIME signatures can be created as well. -To sign an outgoing message, the draft needs to contain a +To encrypt an outgoing message, the draft needs to contain an .Hd Enc header field. -Public keys of all recipients are taken from the gnupg keyring or -from an overrides files, called -.Fn pgpkeys . +Public keys of all recipients are searched for in the gnupg keyring and +in a file called +.Fn pgpkeys , +which contains exceptions and overrides. Unless public keys are found for all recipients, -.Pn send -will refuse to encrypt and send it. +.Pn mhsign +will refuse to encrypt it. Currently, messages with hidden (BCC) recipients can not be encrypted. This work is pending because it requires a structurally more complex approach. .P +.Pn mhpgp +is the companion to +.Pn mhsign . +It verifies signatures and decrypts messages. +Encrypted messages can either be temporarily decrypted for display +or permanently decrypted and stored into the current folder. +Currently, +.Pn mhpgp +needs to be invoked manually. +The integration into +.Pn show +and +.Pn mhstore +to verify signatures and decrypt messages as needs +is planned but not realized yet. +.P +Both scripts were written for nmh, hence they needed to be adjust +according to the differences between nmh and mmh. +For instance, they use the backup prefix no longer. +Further more, compatibility support for old PGP features was dropped. +.P The integrated message signing and encrypting support is one of the most recent features in mmh. -Feedback from users and the experience I will gather myself -will direct the further development of the facility. -It is worthwhile to consider adding +It has not yet had the time to mature. +User feedback and personal experience need to be accumulated to +direct the further development of the facility. +Although the feedback and experience is still missing, +it seems to be worthwhile to consider adding .Sw -[no]sign and .Sw -[no]enc switches to .Pn send , -to override the corresponding header fields. -The profile entry: +to be able to override the corresponding header fields. +A profile entry: .VS send: -sign VE -.LP -would then activate signing of all outgoing messages. -With the present approach, the line -.VS -Send: -VE -.LP -needs to be added to all message forms to achieve the same result. -Yet, the integration of -.Pn mhsign -into mmh is too recent to have enough experience to decide this -question now. -.P -.Pn mhpgp -is the contrary part to -.Pn mhsign . -It verifies signatures and decrypts messages. -.P -FIXME: Add it to mmh first, then write about it here. -.P -The integration of -.Pn mhpgp -into -.Pn show , -to automatically verify signatures and decrypt messages as needed, -is a task left open. -.Pn show 's -current structure does not allow such an integration on basis of -the existing code. -Extensive programming work is required. ... FIXME - +would then activate signing for all outgoing messages. +With the present approach, a +.Hd Send +header component needs to be added to each draft template +to achieve the same result. +Adding the switches would ease the work greatly and keep the +template files clean.