* Bug#6654
@ 2010-07-26 22:10 Dave Goldberg
2010-07-27 4:19 ` Bug#6654 Daiki Ueno
0 siblings, 1 reply; 5+ messages in thread
From: Dave Goldberg @ 2010-07-26 22:10 UTC (permalink / raw)
To: ding
I updated today and was excited to see the ChangeLog entry referring
to the subject bug report, about the inability to encrypt to multiple
recipients using s/mime. I've posted here about that before (which I
mistakenly thought was the same as submitting a bug report) and I've
long had a workaround for it, which I'm pretty sure I've posted here
as well, and am glad to no longer need it.
Well mostly. With the fix, I am indeed now able to use
mml-secure-encrypt-smime and the resulting #secure tag rather than
manually building a multipart. However, by default I am prompted not
only to provide a key (or rather tell Gnus where to look) but also
have to manually figure out which recipient's key I need to specify
for each prompt. For a short list, that's not horrible, but for a
long one, which is something I often have to deal with at work, it's
not hard to miss someone and end up messing up the encryption for
subsequent users on the list. This is a problem I solved as part of
my workaround, which parses the To: Cc: and Gcc: headers to come up
with the list of recipients and fill in the certfile tags based on
that (the Gcc check just results in a call for my personal key if Gcc
exists)
I notice in mml-smime.el a couple of relevant functions with this comment
;; todo: deal with comma separated multiple recipients
so I'm hoping that my code proves useful toward that end. As written
it's tied too closely to a personal cert caching setup I have, which
in turn is tied to how PKI is done at work, so I can't offer it as a
patch, at least not now. It's also only been tested on XEmacs 21.4.
However it does fit the structure of the current mml-smime code in
that it integrates via mml-encrypt-alist.
So with that here is the code.
(setq mml-encrypt-alist
'(("smime" mml-smime-encrypt-buffer dsg-message-make-cert-tags)))
(defun dsg-message-make-cert-tags ()
(let ((certlist
(mapcar 'cadr (mail-extract-address-components
(concat (message-fetch-field "to") ","
(message-fetch-field "cc")) t)))
(gcc-key (if (message-fetch-field "gcc")
(cadar smime-keys)))
certtags)
(while certlist
(setq certtags (append certtags (list 'certfile (dsg-get-address-cert
(car certlist)))))
(setq certlist (cdr certlist)))
(append certtags (list 'certfile gcc-key))))
(defun dsg-get-address-cert (ADDRESS)
;; return expected certificate file name. If non-existent, attempt
;; to get it from LDAP.
(let* ((mailaddr (downcase ADDRESS))
(certfilename
(concat
(expand-file-name mailaddr smime-certificate-directory) ".pem"))
(certbuf (smime-cert-by-ldap mailaddr)))
(cond ((not (or (file-exists-p certfilename) certbuf))
(error "No certificate available for %s" mailaddr))
((and certbuf (not (file-exists-p certfilename)))
(save-excursion
(set-buffer certbuf)
(write-file certfilename))
(kill-buffer certbuf)
certfilename)
(certbuf
(if (get-buffer dsg-cert-buffer)
(progn
(save-excursion
(set-buffer (get-buffer-create dsg-cert-history))
(goto-char (point-max))
(insert-buffer dsg-cert-buffer))
(erase-buffer dsg-cert-buffer)))
(dsg-verify-cert certfilename)
(save-window-excursion
(set-buffer dsg-cert-buffer)
(goto-char (point-min))
(if (looking-at ".*OK$\\|^$")
certfilename
(delete-file certfilename)
(save-excursion
(set-buffer certbuf)
(write-file certfilename)))
(kill-buffer certbuf)
certfilename))
(t certfilename))))
(defun dsg-verify-cert (PEM)
"Verify the certificate stored in PEM"
(interactive (list (read-file-name "Cert file: "
smime-certificate-directory)))
(let ((buffer (get-buffer-create dsg-cert-buffer)))
(save-excursion
(if (fboundp 'set-buffer-file-coding-system)
(set-buffer-file-coding-system 'binary))
(set-buffer buffer)
(goto-char (point-max))
(call-process "openssl" nil t t
"verify" "-CApath" smime-CA-directory
(expand-file-name PEM))
(recenter -1 (get-buffer-window buffer)))
(display-buffer buffer)
(shrink-window-if-larger-than-buffer (get-buffer-window buffer))))
--
Dave Goldberg
david.goldberg6@verizon.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#6654
2010-07-26 22:10 Bug#6654 Dave Goldberg
@ 2010-07-27 4:19 ` Daiki Ueno
2010-07-27 7:26 ` Bug#6654 David Engster
0 siblings, 1 reply; 5+ messages in thread
From: Daiki Ueno @ 2010-07-27 4:19 UTC (permalink / raw)
To: Dave Goldberg; +Cc: ding
Dave Goldberg <david.goldberg6@verizon.net> writes:
> I've posted here about that before (which I mistakenly thought was the
> same as submitting a bug report) and I've long had a workaround for
> it, which I'm pretty sure I've posted here as well, and am glad to no
> longer need it.
Possibly I missed your post, sorry. I personally prefer BTS since it
makes easier to track bugs (particularly longstanding ones).
> ... which parses the To: Cc: and Gcc: headers to come up with the list
> of recipients and fill in the certfile tags based on that (the Gcc
> check just results in a call for my personal key if Gcc exists)
FWIW, you may want to try epg backend of mml-smime. IIRC, it collects
recipient addresses from To/Cc/Bcc, and uses gpgsm (GnuPG's S/MIME tool)
to pick certificate by email address.
Regards,
--
Daiki Ueno
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#6654
2010-07-27 4:19 ` Bug#6654 Daiki Ueno
@ 2010-07-27 7:26 ` David Engster
2010-07-28 1:38 ` Bug#6654 Dave Goldberg
0 siblings, 1 reply; 5+ messages in thread
From: David Engster @ 2010-07-27 7:26 UTC (permalink / raw)
To: Daiki Ueno; +Cc: Dave Goldberg, ding
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Daiki Ueno writes:
> Dave Goldberg <david.goldberg6@verizon.net> writes:
>> ... which parses the To: Cc: and Gcc: headers to come up with the list
>> of recipients and fill in the certfile tags based on that (the Gcc
>> check just results in a call for my personal key if Gcc exists)
>
> FWIW, you may want to try epg backend of mml-smime. IIRC, it collects
> recipient addresses from To/Cc/Bcc, and uses gpgsm (GnuPG's S/MIME tool)
> to pick certificate by email address.
Yes, let me second that. I switched from openssl to gpgsm and I think
it's much more comfortable to use.
However, the epg backend can't yet decrypt S/MIME messages, but I think
it just needs a few lines to add this - see the attached patch. At the
moment it just silently decrypts the message; there should surely be
some hint that this message was actually decrypted, but first I'd like
to know if adding the decryption in mm-view.el is the right choice. I'm
still working on understanding where all the S/MIME decoding is
happening - it seems there is a lot of historical baggage.
-David
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mm-view-smime-decrypt.diff --]
[-- Type: text/x-patch, Size: 1482 bytes --]
diff --git a/lisp/mm-view.el b/lisp/mm-view.el
index 42e21ca..91fba5d 100644
--- a/lisp/mm-view.el
+++ b/lisp/mm-view.el
@@ -669,18 +669,24 @@
(defun mm-view-pkcs7-decrypt (handle)
(insert-buffer-substring (mm-handle-buffer handle))
(goto-char (point-min))
- (insert "MIME-Version: 1.0\n")
- (mm-insert-headers "application/pkcs7-mime" "base64" "smime.p7m")
- (smime-decrypt-region
- (point-min) (point-max)
- (if (= (length smime-keys) 1)
- (cadar smime-keys)
- (smime-get-key-by-email
- (completing-read
- (concat "Decipher using key"
- (if smime-keys (concat "(default " (caar smime-keys) "): ")
- ": "))
- smime-keys nil nil nil nil (car-safe (car-safe smime-keys))))))
+ (if (eq mml-smime-use 'epg)
+ ;; Use EPG/gpgsm
+ (let ((part (base64-decode-string (buffer-string))))
+ (erase-buffer)
+ (insert (epg-decrypt-string (epg-make-context 'CMS) part)))
+ ;; Use openssl
+ (insert "MIME-Version: 1.0\n")
+ (mm-insert-headers "application/pkcs7-mime" "base64" "smime.p7m")
+ (smime-decrypt-region
+ (point-min) (point-max)
+ (if (= (length smime-keys) 1)
+ (cadar smime-keys)
+ (smime-get-key-by-email
+ (completing-read
+ (concat "Decipher using key"
+ (if smime-keys (concat "(default " (caar smime-keys) "): ")
+ ": "))
+ smime-keys nil nil nil nil (car-safe (car-safe smime-keys)))))))
(goto-char (point-min))
(while (search-forward "\r\n" nil t)
(replace-match "\n"))
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#6654
2010-07-27 7:26 ` Bug#6654 David Engster
@ 2010-07-28 1:38 ` Dave Goldberg
2010-07-28 5:35 ` gpgsm for S/MIME (was Re: Bug#6654) David Engster
0 siblings, 1 reply; 5+ messages in thread
From: Dave Goldberg @ 2010-07-28 1:38 UTC (permalink / raw)
To: ding
> Daiki Ueno writes:
>> Dave Goldberg <david.goldberg6@verizon.net> writes:
>>> ... which parses the To: Cc: and Gcc: headers to come up with the list
>>> of recipients and fill in the certfile tags based on that (the Gcc
>>> check just results in a call for my personal key if Gcc exists)
>>
>> FWIW, you may want to try epg backend of mml-smime. IIRC, it collects
>> recipient addresses from To/Cc/Bcc, and uses gpgsm (GnuPG's S/MIME tool)
>> to pick certificate by email address.
Thanks for that tip. I seem to recall a post suggesting the use of
epg and gpgsm for s/mime but was not aware anything had made it into
the code yet. I'll give it a try.
> Yes, let me second that. I switched from openssl to gpgsm and I think
> it's much more comfortable to use.
> However, the epg backend can't yet decrypt S/MIME messages, but I think
> it just needs a few lines to add this - see the attached patch. At the
> moment it just silently decrypts the message; there should surely be
> some hint that this message was actually decrypted, but first I'd like
> to know if adding the decryption in mm-view.el is the right choice. I'm
> still working on understanding where all the S/MIME decoding is
> happening - it seems there is a lot of historical baggage.
I'll have to try that patch as decrypting and viewing is nearly as
important to me as being able to encrypt :-) If not, do the back ends
allow one to use gpgsm for sending and the old openssl mode for
reading? Yeah, I know, I'll go RTFS ;-)
Thanks,
--
Dave Goldberg
david.goldberg6@verizon.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* gpgsm for S/MIME (was Re: Bug#6654)
2010-07-28 1:38 ` Bug#6654 Dave Goldberg
@ 2010-07-28 5:35 ` David Engster
0 siblings, 0 replies; 5+ messages in thread
From: David Engster @ 2010-07-28 5:35 UTC (permalink / raw)
To: ding
Dave Goldberg writes:
> I'll have to try that patch as decrypting and viewing is nearly as
> important to me as being able to encrypt :-) If not, do the back ends
> allow one to use gpgsm for sending and the old openssl mode for
> reading?
Yes. Actually, that's what currently happening for decrypting S/MIME, so
if you've already got through the tedious openssl setup, you should be
fine.
The main advantage of gpgsm is that is has adopted the GPG-style key
management for certificates, so it's pretty straightforward to use. If
you verify a signed mail, you'll automatically have the sender's
certificate for future use. With openssl, I used a pretty lengthy code
snippet to snarf the certificate, save it and put a link to it in the
BBDB.
Also, the gpg-agent will take care of securely asking for passwords and
caching (although this can be a disadvantage if you're working on the
console; it is not always clear on which tty the dialog will pop up, but
you can always "seed" the agent with the password beforehand).
-David
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-28 5:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-26 22:10 Bug#6654 Dave Goldberg
2010-07-27 4:19 ` Bug#6654 Daiki Ueno
2010-07-27 7:26 ` Bug#6654 David Engster
2010-07-28 1:38 ` Bug#6654 Dave Goldberg
2010-07-28 5:35 ` gpgsm for S/MIME (was Re: Bug#6654) David Engster
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).