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

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

bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default t


From: Daniel Kahn Gillmor
Subject: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Date: Wed, 25 Jan 2017 15:30:33 -0500

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 <address@hidden> 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 address@hidden 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

Attachment: signature.asc
Description: PGP signature


reply via email to

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