GNU bug report logs - #40397
28.0.50; epg decrypt does not verify signed content in smime encrypted and signed message

Previous Next

Packages: emacs, gnus;

Reported by: Sebastian Fieber <sebastian.fieber <at> web.de>

Date: Thu, 2 Apr 2020 23:38:03 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Sebastian Fieber <sebastian.fieber <at> web.de>
To: 40397 <at> debbugs.gnu.org
Subject: bug#40397: 28.0.50; epg decrypt does not verify signed content in smime
Date: Sat, 04 Apr 2020 01:22:06 +0200
[Message part 1 (text/plain, inline)]
Hey,

Just forget my last mail. I just dug a bit deeper and found the culprit
I think.

With commit 84ef1ea8b524f8998fc8674b99cf8069e38dce4f these lines were
added:

--8<---------------cut here---------------start------------->8---
modified   lisp/gnus/mm-decode.el
@@ -1672,6 +1672,8 @@ If RECURSIVE, search recursively."
                    (t (y-or-n-p
                        (format "Decrypt (S/MIME) part? "))))
                   (mm-view-pkcs7 parts from))
+         (goto-char (point-min))
+         (insert "Content-type: text/plain\n\n")
          (setq parts (mm-dissect-buffer t)))))
      ((equal subtype "signed")
       (unless (and (setq protocol
@@ -1739,6 +1741,7 @@ If RECURSIVE, search recursively."
--8<---------------cut here---------------end--------------->8---

I don't quite know why the content-type is forced here to text/plain. So
if this line is removed the mm-dissect-buffer call does it's thing and
returns correctly whats inside the envelope (the real content-type
header in the decrypted envelope is parsed). Well almost...

I wrote in my last mail that I had to adjust mm-copy-to-buffer:

> and also mm-copy-to-buffer to check for carriage returns like this:
>
> (search-forward-regexp "^\r\n" nil 'move)
>
> (can't send the carriage return properly so \r it is here instead of ^M)

This is still needed as the decrypted content may still have carriage
returns in it. One could also remove the carriage returns in
mm-view-pkcs7-decrypt function of course. I'm not quite sure which is
the better approach.

In such a case the "Decrypt (S/MIME) part?" is asked too times. But hey
that isn't too bad I think.

I have attached a patch with the explained fix.

Best regards
Sebastian

[0001-fix-bug-40397.patch (text/x-patch, attachment)]

This bug report was last modified 3 years and 208 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.