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