GNU bug report logs -
#17338
Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Previous Next
Reported by: Rob Browning <rlb <at> defaultvalue.org>
Date: Fri, 25 Apr 2014 01:45:01 UTC
Severity: normal
Tags: security
Merged with 17391
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17338 in the body.
You can then email your comments to 17338 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17338; Package
emacs.
(Fri, 25 Apr 2014 01:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Rob Browning <rlb <at> defaultvalue.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 25 Apr 2014 01:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[If possible, please preserve the 745553-forwarded address in any replies.]
This bug was filed recently, and I suspect it might be something you'd
like to discuss upstream.
Thanks
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> Package: emacs24-el
> Version: 24.3+1-2
> Severity: normal
>
> Hi emacs maintainers!
>
> in
>
> /usr/share/emacs/24.3/lisp/gnus/mml2015.el.gz
>
> i see this variable definition:
>
> (defcustom mml2015-always-trust t
> "If t, GnuPG skip key validation on encryption."
> :group 'mime-security
> :type 'boolean)
>
> This is a security risk for users of encrypted mail. i believe it
> should be set to nil by default.
>
> Here's why:
>
> Consider Alice, who has OpenPGP certificates for "Bob
> <bob <at> example.org>" and "Carol <carol <at> example.org>" in her keyring (in
> that order). She has certified them both, so there is one valid
> primary key for bob <at> example.org and one valid primary key for
> alice <at> example.org.
>
> Bob turns evil (or maybe his key is compromised) and he adds a new
> User ID: "Bob <carol <at> example.org>" to his OpenPGP cert. He publishes
> the update to the keyservers.
>
> Alice, following best practices, updates her keyring from the
> keyservers regularly.
>
> Alice's keyring now has two certs that have a "carol <at> example.org" user
> ID in them. One of them is valid, and the other one is not.
>
> Alice now composes a message to "Carol <carol <at> example.org>" and marks
> it with:
>
> <#secure method=pgpmime mode=signencrypt>
>
> As the message goes out, mml-mode just passes the e-mail address
> carol <at> example.org to gpg to encrypt the message body, and gpg uses the
> e-mail address to select a key. Since Bob's key is first in the
> keyring, it is the one that will be used.
>
> Bob then sneaks a peak at Carol's e-mail (maybe they're delivered to the
> same server, or he has a machine on the same network), catches the
> message in transit, and can decrypt the content, violating Alice's
> message confidentiality expectations.
>
> Please set mml2015-always-trust to default to "nil" instead of "t".
>
> --dkg
>
> -- System Information:
> Debian Release: jessie/sid
> APT prefers testing
> APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages emacs24-el depends on:
> ii emacs24-common 24.3+1-2
>
> emacs24-el recommends no packages.
>
> emacs24-el suggests no packages.
>
> -- debconf-show failed
>
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Merged 17338 17391.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 02 May 2014 21:14:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Wed, 25 Jan 2017 17:23:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 17338 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> So in the scenario above, Bob's cert is still overall valid (because it
> has a valid certification over the correct UserID+key from Alice), even
> though the carol <at> example.org UserID is invalid.
>
> I don't know mml-mode or elisp well enough to dig into the code and fix
> this part of the problem quickly, but if someone has patches that i can
> look at that would point to where it might be changed, i'd be happy to
> try to review them.
I'm also mostly unfamiliar with the mml encryption code, but perhaps
Jens could take a peek at this?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:10:04 GMT)
Full text and
rfc822 format available.
Message #13 received at 17338 <at> debbugs.gnu.org (full text, mbox):
On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:
> Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
>
>> So in the scenario above, Bob's cert is still overall valid (because it
>> has a valid certification over the correct UserID+key from Alice), even
>> though the carol <at> example.org UserID is invalid.
>>
>> I don't know mml-mode or elisp well enough to dig into the code and fix
>> this part of the problem quickly, but if someone has patches that i can
>> look at that would point to where it might be changed, i'd be happy to
>> try to review them.
>
> I'm also mostly unfamiliar with the mml encryption code, but perhaps
> Jens could take a peek at this?
mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
nowadays. I certainly wouldn’t object if the default value was
changed, but lots of long-term users might be surprised.
Also, nowadays, if multiple keys are available for a recipient, the
user is asked which key to use and whether to store that choice.
Then, EasyPG is responsible for calling GnuPG. Maybe something
needs to be adjusted there as well. What is the expected command
line behavior?
Best wishes
Jens
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:31:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 17338 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 18:19, Lars Ingebrigtsen wrote:
>
>> Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
>>
>>> So in the scenario above, Bob's cert is still overall valid (because it
>>> has a valid certification over the correct UserID+key from Alice), even
>>> though the carol <at> example.org UserID is invalid.
>>>
>>> I don't know mml-mode or elisp well enough to dig into the code and fix
>>> this part of the problem quickly, but if someone has patches that i can
>>> look at that would point to where it might be changed, i'd be happy to
>>> try to review them.
>>
>> I'm also mostly unfamiliar with the mml encryption code, but perhaps
>> Jens could take a peek at this?
>
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays. I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.
It's also possible that lots of long-term users might be surprised to
find that refreshing one key in their keyring is likely to cause a
change in behavior for the use of other keys in their keyring. this is
a silent surprise, which seems worse than a public surprise.
> Also, nowadays, if multiple keys are available for a recipient, the
> user is asked which key to use and whether to store that choice.
And how is that choice stored? How and when can it be revisited by the
user? What happens if that choice becomes invalid in the future
(e.g. the primary key, or the encryption-capable subkey is revoked,
expired, etc)?
> Then, EasyPG is responsible for calling GnuPG. Maybe something
> needs to be adjusted there as well. What is the expected command
> line behavior?
Modern versions of GnuPG automatically select the key which GnuPG knows
to have the best validity among all matches for the selector, thanks to
work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
would relieve emacs of most of the hard work here, and would also mean
that any changes that the user makes to their GnuPG keyring would
automatically take effect in emacs without mml-mode needing to do
anything.
Modern versions of GnuPG also provide a "tofu" mechanism to store and
track that kind of decision in. Neal Walfield (also cc'ed here) put in
a lot of that implementation, so he might have some suggestions for the
best way to handle it.
Thanks for looking into this, Lars and Jens!
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Thu, 26 Jan 2017 18:37:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 17338 <at> debbugs.gnu.org (full text, mbox):
On 2017-01-25, at 15:30, Daniel Kahn Gillmor wrote:
> On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
>> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
>> nowadays. I certainly wouldn’t object if the default value was
>> changed, but lots of long-term users might be surprised.
>
> It's also possible that lots of long-term users might be surprised to
> find that refreshing one key in their keyring is likely to cause a
> change in behavior for the use of other keys in their keyring. this is
> a silent surprise, which seems worse than a public surprise.
Sorry, I don’t understand this. What change in one key is causing
silent changes for other keys?
>> Also, nowadays, if multiple keys are available for a recipient, the
>> user is asked which key to use and whether to store that choice.
>
> And how is that choice stored? How and when can it be revisited by the
> user? What happens if that choice becomes invalid in the future
> (e.g. the primary key, or the encryption-capable subkey is revoked,
> expired, etc)?
That’s customized in mml-secure-key-preferences. So, the usual
customize interface is available. And there is some code to detect
and remove unusable customizations.
>> Then, EasyPG is responsible for calling GnuPG. Maybe something
>> needs to be adjusted there as well. What is the expected command
>> line behavior?
>
> Modern versions of GnuPG automatically select the key which GnuPG knows
> to have the best validity among all matches for the selector, thanks to
> work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
> would relieve emacs of most of the hard work here, and would also mean
> that any changes that the user makes to their GnuPG keyring would
> automatically take effect in emacs without mml-mode needing to do
> anything.
The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes
use of sub-keys and their IDs for encryption commands, instead of
relying on GnuPG’s selections.
> Modern versions of GnuPG also provide a "tofu" mechanism to store and
> track that kind of decision in. Neal Walfield (also cc'ed here) put in
> a lot of that implementation, so he might have some suggestions for the
> best way to handle it.
If Emacs was relying on GnuPG’s decisions, nothing special would be
necessary for tofu, right? (Users could activate that in their
gpg.conf.)
Best wishes
Jens
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Thu, 26 Jan 2017 19:36:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 17338 <at> debbugs.gnu.org (full text, mbox):
Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:
>> Modern versions of GnuPG automatically select the key which GnuPG knows
>> to have the best validity among all matches for the selector, thanks to
>> work put in by Justus Winter (cc'ed), so letting GnuPG make the decision
>> would relieve emacs of most of the hard work here, and would also mean
>> that any changes that the user makes to their GnuPG keyring would
>> automatically take effect in emacs without mml-mode needing to do
>> anything.
>
> The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes
> use of sub-keys and their IDs for encryption commands, instead of
> relying on GnuPG’s selections.
It was suggested by Werner to do key selection in Emacs, like GPGME. I
don't know whether GPGME changed the logic though.
>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>> track that kind of decision in. Neal Walfield (also cc'ed here) put in
>> a lot of that implementation, so he might have some suggestions for the
>> best way to handle it.
I'm afraid I wouldn't do any work toward tofu at this level of quality;
in particular, until they reach the consensus whether tofu is only
activated when encryption is triggered by an email address.
Regards,
--
Daiki Ueno
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 17338 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays. I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.
hm, i just noticed that mml-secure-openpgp-always-trust isn't in emacs24
either. is this also limited to emacs25? Maybe this change of variable
is a good chance to do the transition to a better default.
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 17338 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
> Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:
>> The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes
>> use of sub-keys and their IDs for encryption commands, instead of
>> relying on GnuPG’s selections.
>
> It was suggested by Werner to do key selection in Emacs, like GPGME. I
> don't know whether GPGME changed the logic though.
I don't know what this means -- i don't think that GPGME itself does key
selection. Can you tell me more?
Presumably users who use emacs with gpg also use gpg with other tools
(possibly even other MUAs), or even gpg on its own. Collecting key
preference data in multiple places while sharing the underlying key
store seems like a recipe for synchronization problems and confusing
behavior, particularly for folks who don't know how the tools fit
together.
>>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>>> track that kind of decision in. Neal Walfield (also cc'ed here) put in
>>> a lot of that implementation, so he might have some suggestions for the
>>> best way to handle it.
>
> I'm afraid I wouldn't do any work toward tofu at this level of quality;
> in particular, until they reach the consensus whether tofu is only
> activated when encryption is triggered by an email address.
I don't think i understand this either. Can you explain more about what
you need from the GnuPG TOFU code?
Thanks for this discussion, hopefully it'll lead somewhere fruitful.
--dkg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:03 GMT)
Full text and
rfc822 format available.
Message #31 received at 17338 <at> debbugs.gnu.org (full text, mbox):
On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 15:30, Daniel Kahn Gillmor wrote:
>> On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
>>> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
>>> nowadays. I certainly wouldn’t object if the default value was
>>> changed, but lots of long-term users might be surprised.
>>
>> It's also possible that lots of long-term users might be surprised to
>> find that refreshing one key in their keyring is likely to cause a
>> change in behavior for the use of other keys in their keyring. this is
>> a silent surprise, which seems worse than a public surprise.
>
> Sorry, I don’t understand this. What change in one key is causing
> silent changes for other keys?
Without the notification that multiple keys are available, Bob can add
Carol's User ID to his cert ; depending on where the certs are
positioned linearly in Alice's keyring, mail to Carol might be encrypted
to Bob's key, or to Alice's key.
I think this is mitigated at least in part by prompting the user when
there are multiple keys available, though.
> That’s customized in mml-secure-key-preferences. So, the usual
> customize interface is available. And there is some code to detect
> and remove unusable customizations.
When was this introduced? i don't see it, but then i'm still using
emacs24. Do i need to upgrade?
>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>> track that kind of decision in. Neal Walfield (also cc'ed here) put in
>> a lot of that implementation, so he might have some suggestions for the
>> best way to handle it.
>
> If Emacs was relying on GnuPG’s decisions, nothing special would be
> necessary for tofu, right? (Users could activate that in their
> gpg.conf.)
Neal can answer this better than i can. I think the TOFU mode works
best when there's a bit of UI integration -- emacs would provide the way
for the user to answer a question prompted by gpg, and then gpg is
responsible for storing/tracking all the info.
--dkg
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Fri, 27 Jan 2017 02:51:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 17338 <at> debbugs.gnu.org (full text, mbox):
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
>> Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:
>>> The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes
>>> use of sub-keys and their IDs for encryption commands, instead of
>>> relying on GnuPG’s selections.
>>
>> It was suggested by Werner to do key selection in Emacs, like GPGME. I
>> don't know whether GPGME changed the logic though.
>
> I don't know what this means -- i don't think that GPGME itself does key
> selection. Can you tell me more?
My wording might be confusing; let me rephase: I don't think GPGME has a
means of using GnuPG's selections, which the applications can rely on.
EasyPG is modelled after GPGME, and Gnus is an application using it,
thus it is a responsiblity of Gnus to select usable keys by itself.
> Presumably users who use emacs with gpg also use gpg with other tools
> (possibly even other MUAs), or even gpg on its own. Collecting key
> preference data in multiple places while sharing the underlying key
> store seems like a recipe for synchronization problems and confusing
> behavior, particularly for folks who don't know how the tools fit
> together.
If there is the means to do that in GPGME now, yes, it would be nice for
EasyPG to provide a similar mechanism which can be used from Gnus.
Otherwise, IMO, neither EasyPG nor Gnus should try to do the selection
by calling gpg directly, even if it could be useful.
Regards,
--
Daiki Ueno
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Fri, 27 Jan 2017 06:46:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 17338 <at> debbugs.gnu.org (full text, mbox):
On 2017-01-26, at 18:13, Daniel Kahn Gillmor wrote:
> On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:
>> That’s customized in mml-secure-key-preferences. So, the usual
>> customize interface is available. And there is some code to detect
>> and remove unusable customizations.
>
> When was this introduced? i don't see it, but then i'm still using
> emacs24. Do i need to upgrade?
I introduced that about a year ago, when Gnus was still developed in
its own repository. I don’t know anything about Gnus releases since
then.
The doc string reports those changes as of version 25.1 of Emacs.
Best wishes
Jens
Added tag(s) security.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 18 Dec 2018 22:32:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#17338; Package
emacs,gnus.
(Sun, 20 Feb 2022 13:12:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 17338 <at> debbugs.gnu.org (full text, mbox):
Jens Lechtenboerger <jens.lechtenboerger <at> fsfe.org> writes:
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays. I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.
>
> Also, nowadays, if multiple keys are available for a recipient, the
> user is asked which key to use and whether to store that choice.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Skimming this bug report, it seems like this is working as designed, so
I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
17391 <at> debbugs.gnu.org and Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 20 Feb 2022 13:12:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 21 Mar 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 88 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.