unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Jens Lechtenboerger <jens.lechtenboerger@fsfe.org>,
	Lars Ingebrigtsen <larsi@gnus.org>
Cc: 745553@bugs.debian.org, 17338@debbugs.gnu.org,
	Justus Winter <justus@g10code.com>,
	745553-forwarded@bugs.debian.org, 17391@debbugs.gnu.org,
	rlb@defaultvalue.org, "Neal H. Walfield" <neal@walfield.org>
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	[thread overview]
Message-ID: <87a8aenaqe.fsf@alice.fifthhorseman.net> (raw)
In-Reply-To: <87a8aehpf8.fsf@informationelle-selbstbestimmung-im-internet.de>

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-01-25 20:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140422190613.18043.21415.reportbug@alice.fifthhorseman.net>
2014-04-24 19:12 ` Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t Rob Browning
2014-05-02 20:29   ` Daniel Kahn Gillmor
2017-01-25 17:19     ` bug#17391: " Lars Ingebrigtsen
2017-01-25 20:09       ` bug#17338: " Jens Lechtenboerger
2017-01-25 20:30         ` Daniel Kahn Gillmor [this message]
2017-01-26 18:36           ` Jens Lechtenboerger
2017-01-26 19:34             ` Daiki Ueno
2017-01-26 23:17               ` bug#17338: " Daniel Kahn Gillmor
2017-01-27  2:49                 ` Daiki Ueno
2017-01-27  2:49                 ` Daiki Ueno
2017-01-26 23:13             ` bug#17338: " Daniel Kahn Gillmor
2017-01-27  6:45               ` Jens Lechtenboerger
2017-01-26 23:19         ` Daniel Kahn Gillmor
2022-02-20 13:11         ` bug#17338: " Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8aenaqe.fsf@alice.fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=17338@debbugs.gnu.org \
    --cc=17391@debbugs.gnu.org \
    --cc=745553-forwarded@bugs.debian.org \
    --cc=745553@bugs.debian.org \
    --cc=jens.lechtenboerger@fsfe.org \
    --cc=justus@g10code.com \
    --cc=larsi@gnus.org \
    --cc=neal@walfield.org \
    --cc=rlb@defaultvalue.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).