bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40118: 27.0.90; Signing emails with gpg


From: Robert Pluim
Subject: bug#40118: 27.0.90; Signing emails with gpg
Date: Thu, 16 Apr 2020 12:38:13 +0200

>>>>> On Thu, 16 Apr 2020 13:15:02 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: stepnem@gmail.com,  40118@debbugs.gnu.org,  
boudiccas@skimble.plus.com
    >> Date: Thu, 16 Apr 2020 11:44:51 +0200
    >> 
    >> In emacs-26, mml-secure-epg-sign could specify that a message should
    >> be signed with a key based on the senderʼs email address. If the
    >> variable governing that was nil, it was left to gpg to figure out the
    >> key to use. Normally that means gpg uses its default key.
    >> 
    >> In emacs-27, mml-secure-epg-sign now checks explicitly whether that
    >> variable is nil, and refuses to continue.

    Eli> Why was this change in behavior made in Emacs 27?

I donʼt know. Lars? (and why only for signing and not encrypting?)

    commit 9c81149ae9165b0f017d60d141221b340879baef
    Author: Lars Ingebrigtsen <larsi@gnus.org>
    Date:   Wed Oct 9 21:55:41 2019 +0200

        Make mml-secure-epg-sign bug out if we can't find an identity

        * lisp/gnus/mml-sec.el (mml-secure-epg-sign): Bug out if we
        couldn't find anything to sign with instead of silently pretending
        to sign.

    >> With an error message that in at least 50% of the cases points the
    >> user to the wrong user option. This is a regression from emacs-26.
    >> 
    >> Fixing the error message is easy. Iʼm proposing that by default the
    >> senderʼs email address is used to determine the key to use, since
    >> thatʼs what almost everyone will want. People who donʼt want that can
    >> control the behaviour by either adding keys to
    >> 'mml-secure-openpgp-signers' or by setting 'mm-sign-option' to
    >> 'guided.

    Eli> I'd prefer to have a behavior that didn't require any changes, if
    Eli> possible.  Thus the above question.  If having a compatible behavior
    Eli> is impractical, then let's discuss what would the lesser evil.

setting mml-secure-smime-sign-with-sender and
mml-secure-openpgp-sign-with-sender to t gets us back to the previous
behaviour in the default case. People that didnʼt want that behaviour
would already have set mml-secure-openpgp-signers and/or
mm-sign-option.

Actually, setting those two options to t would result in a behaviour
change for people who use mml-secure-{openpgp,smime}-signers to select a
signing key thatʼs not the same as the one for the sender. I think
those people fall in the 'know what theyʼre doing' category, and they
can set them back to nil.

I think the absolute minimum we should do for emacs-27 is this:

diff --git a/lisp/gnus/mml-sec.el b/lisp/gnus/mml-sec.el
index 740e1d2b72..395c1e8253 100644
--- a/lisp/gnus/mml-sec.el
+++ b/lisp/gnus/mml-sec.el
@@ -946,12 +946,14 @@ mml-secure-epg-sign
         signature micalg)
     (unless signers
       (let ((maybe-msg
-             (if mml-secure-smime-sign-with-sender
+             (if (or mml-secure-smime-sign-with-sender
+                     mml-secure-openpgp-sign-with-sender)
                  "."
-               "; try setting `mml-secure-smime-sign-with-sender'.")))
-        ;; If `mml-secure-smime-sign-with-sender' is already non-nil
-        ;; then there's no point advising the user to examine it.  If
-        ;; there are any other variables worth examining, please
+               "; try setting `mml-secure-smime-sign-with-sender' or 
'mml-secure-openpgp-sign-with-sender'.")))
+        ;; If `mml-secure-smime-sign-with-sender' or
+        ;; `mml-secure-openpgp-sign-with-sender' are already non-nil
+        ;; then there's no point advising the user to examine them.
+        ;; If there are any other variables worth examining, please
         ;; improve this error message by having it mention them.
         (error "Couldn't find any signer names%s" maybe-msg)))
     (when (eq 'OpenPGP protocol)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]