Browse Source

Fix a bug when checking signatures accidentally containing CRLF

From our previous attempts to get S/MIME working when using Outlook, the
function `mm-copy-to-buffer` had been adviced to change all LF to CRLF, to allow
`mm-copy-to-buffer` to find the beginning of the body.  However, when the body
itself is binary and accidentally contains an CRLF, that content is modified as
well.  This might break the content, as it happend with the signature of
elpa.gnu.org, which indeed contained an CRLF.

We are now a bit more non-invasive and replace the original version of
`mm-copy-to-buffer` with one that explicitly also searches for ^\r\n in addition
to just ^\n.  Let's see how good that will work.  Signature checking for
elpa.gnu.org is functioning again, and S/MIME still seems to be working.
master
Daniel 11 months ago
parent
commit
6dd6cf88ab
No known key found for this signature in database GPG Key ID: 1C7071A75BB72D64
  1. 25
      init.el

25
init.el

@ -1675,11 +1675,24 @@
;; header by searching ^\n; however, if we received mail from
;; Outlook, there's an ^\r\n seperating header and body, which is
;; not found by `mm-copy-to-buffer', leaving the target buffer empty
;; and the mail as well. Replacing all \r\n with \n before copying
;; buffers seems to help.
(advice-add 'mm-copy-to-buffer
:before #'db/convert-crlf-to-lf-in-buffer)))
;; and the mail as well. Redefining `mm-copy-to-buffer' to also
;; search for ^\r\n might help.
(defun mm-copy-to-buffer ()
"Copy the contents of the current buffer to a fresh buffer."
(let ((obuf (current-buffer))
(mb enable-multibyte-characters)
beg)
(goto-char (point-min))
;; The following regex has been extended by \r? .
(search-forward-regexp "^\r?\n" nil 'move) ;; There might be no body.
(setq beg (point))
(with-current-buffer
(generate-new-buffer " *mm*")
;; Preserve the data's unibyteness (for url-insert-file-contents).
(set-buffer-multibyte mb)
(insert-buffer-substring obuf beg)
(current-buffer))))))
(setq message-forward-as-mime nil)
@ -1721,7 +1734,7 @@
;; Outlook seems to expect \r\n in PKCS#7 encrypted containers, but
;; Gnus is only sending \n; so let's artificially replace \n by \r\n
;; before, well, signing? Seems to work at least in the case where
;; we are sending S/MIME encrypted and signed messages
;; we are sending S/MIME encrypted and signed messages.
(advice-add 'mml-smime-epg-sign
:after #'db/convert-lf-to-crlf-in-buffer) ))

Loading…
Cancel
Save