GNU bug report logs -
#17391
Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17391 in the body.
You can then email your comments to 17391 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#17391; Package
emacs.
(Fri, 02 May 2014 20:39:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 02 May 2014 20:39:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/24/2014 03:12 PM, Rob Browning wrote:
> [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 for forwarding this, Rob.
More notes below:
> Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
[...]
>> 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.
Turns out the situation is slightly worse than i described above. While
i still think that mml2015-always-trust should default to nil (and this
defends against some failure modes), there are other problems with key
selection that aren't fixed yet.
In particular, the problematic scenario described above is *not* fixed
by changing the setting. Observing the behavior, it looks like mml-mode
does OpenPGP certificate selection by e-mail address in the following
way (sorry i haven't dug into the code yet):
0) it asks GnuPG for a cert associated with the given e-mail address
1) it checks the *overall* validity of the cert in order to decide if
the cert is the right one
2) if the cert is valid, it encrypts to it.
The problem with this is how gpg defines the overall validity of the
cert: in particular, it defines the validity of a cert as the *highest*
validity of any UserID associated with the cert. It should instead be
looking at the validity of the desired User ID specifically, not the
overall cert.
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.
--dkg
[signature.asc (application/pgp-signature, attachment)]
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#17391; Package
emacs,gnus.
(Wed, 25 Jan 2017 17:23:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 17391 <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#17391; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:10:05 GMT)
Full text and
rfc822 format available.
Message #13 received at 17391 <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#17391; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:31:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 17391 <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#17391; Package
emacs,gnus.
(Thu, 26 Jan 2017 18:37:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 17391 <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#17391; Package
emacs,gnus.
(Thu, 26 Jan 2017 19:36:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 17391 <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#17391; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:03 GMT)
Full text and
rfc822 format available.
Message #25 received at 17391 <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#17391; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:04 GMT)
Full text and
rfc822 format available.
Message #28 received at 17391 <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#17391; Package
emacs,gnus.
(Thu, 26 Jan 2017 23:20:04 GMT)
Full text and
rfc822 format available.
Message #31 received at 17391 <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#17391; Package
emacs,gnus.
(Fri, 27 Jan 2017 02:51:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 17391 <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#17391; Package
emacs,gnus.
(Fri, 27 Jan 2017 06:46:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 17391 <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#17391; Package
emacs,gnus.
(Sun, 20 Feb 2022 13:12:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 17391 <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 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.