From: Jens Lechtenboerger <jens.lechtenboerger@fsfe.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 745553@bugs.debian.org, 17338@debbugs.gnu.org,
Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
745553-forwarded@bugs.debian.org, 17391@debbugs.gnu.org,
rlb@defaultvalue.org
Subject: bug#17338: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Date: Wed, 25 Jan 2017 21:09:47 +0100 [thread overview]
Message-ID: <87a8aehpf8.fsf@informationelle-selbstbestimmung-im-internet.de> (raw)
In-Reply-To: <87k29jvyzc.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 25 Jan 2017 18:19:35 +0100")
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.
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
next prev parent reply other threads:[~2017-01-25 20:09 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 ` Jens Lechtenboerger [this message]
2017-01-25 20:30 ` Daniel Kahn Gillmor
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 ` bug#17338: " Daiki Ueno
2017-01-26 23:13 ` 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=87a8aehpf8.fsf@informationelle-selbstbestimmung-im-internet.de \
--to=jens.lechtenboerger@fsfe.org \
--cc=17338@debbugs.gnu.org \
--cc=17391@debbugs.gnu.org \
--cc=745553-forwarded@bugs.debian.org \
--cc=745553@bugs.debian.org \
--cc=dkg@fifthhorseman.net \
--cc=larsi@gnus.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).