From: Robert Pluim <rpluim@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>, Richard Stallman <rms@gnu.org>,
emacs-devel@gnu.org
Subject: Re: Deprecate TLS1.0 support in emacs
Date: Tue, 01 Aug 2017 17:12:53 +0200 [thread overview]
Message-ID: <87vam7uxsa.fsf@gmail.com> (raw)
In-Reply-To: <87pocfibky.fsf@mouse> (Lars Ingebrigtsen's message of "Tue, 01 Aug 2017 16:53:17 +0200")
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Paul Eggert <eggert@cs.ucla.edu> writes:
>
>> Last year I would have agreed, but nowadays I think it'd be better to
>> warn about TLS 1.0 somehow. According to
>> https://www.ssllabs.com/ssl-pulse/ from July 2016 to July 2017 TLS
>> v1.2 support climbed from 78.3% to 87.3%, whereas support for TLS v1.0
>> dropped from 97.3% to to 93.4% as the higher-end sites tighten up
>> security. By the time the next version of Emacs comes out, it looks
>> like a mild warning about TLS v1.0 will be appropriate.
>
> Yes, I agree. eww, for instance, could remove the green URL when using
> TLS 1.0, etc. But the proposed NSM warning (which would make the user
> answer "y" to a direct question about the TLS-ness) is too heavy, in my
> opinion.
OK. I happen to like NSM, mainly because I like explicit and detailed
messages from my tools, rather than having them change visual
indicators, but mileage obviously varies.
> But having the warning on the `high' NSM setting is fine with me, and
> I'll see what I can do about removing green URLs from eww...
Is that an offer to commit my patch? :-)
There's 🔐 and 🔓 you can use if you feel like getting fancy. Changing
the colour of the URL doesn't speak to me very much.
> Other services, like SMTP/IMAP/etc will have to invent other
> "lightweight" ways to tell the user that the content is on the insecure
> side.
I'm not sure how you can signal that someone's SMTP/IMAP session is
using an insecure protocol without ending up back at NSM.
Robert
next prev parent reply other threads:[~2017-08-01 15:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 13:03 Deprecate TLS1.0 support in emacs Robert Pluim
2017-07-12 13:48 ` Lars Ingebrigtsen
2017-07-12 14:30 ` Robert Pluim
2017-07-12 14:36 ` Andreas Schwab
2017-07-12 14:39 ` Robert Pluim
2017-07-12 14:55 ` Andreas Schwab
2017-07-12 15:59 ` Robert Pluim
2017-07-12 14:44 ` Lars Ingebrigtsen
2017-07-12 16:10 ` Robert Pluim
2017-07-12 19:05 ` Lars Ingebrigtsen
2017-07-13 8:45 ` Robert Pluim
2017-07-13 12:25 ` Richard Stallman
2017-07-13 13:29 ` Robert Pluim
2017-08-01 12:02 ` Robert Pluim
2017-08-01 12:38 ` Lars Ingebrigtsen
2017-08-01 13:01 ` Robert Pluim
2017-08-01 14:45 ` Paul Eggert
2017-08-01 14:53 ` Lars Ingebrigtsen
2017-08-01 15:12 ` Robert Pluim [this message]
2017-08-01 17:56 ` Stefan Monnier
2017-08-03 11:48 ` Lars Ingebrigtsen
2017-08-03 15:52 ` Stefan Monnier
2017-08-03 19:30 ` Ted Zlatanov
2017-08-04 5:40 ` Eli Zaretskii
2017-08-04 13:13 ` Ted Zlatanov
2017-08-04 14:51 ` Eli Zaretskii
2017-08-04 17:26 ` Stefan Monnier
2017-08-04 19:50 ` Ted Zlatanov
2017-08-04 21:21 ` Stefan Monnier
2017-08-04 23:09 ` Ted Zlatanov
2017-08-05 7:21 ` Michael Albinus
2017-08-06 19:17 ` common Emacs notifications and alert.el (John W.) package (was: Deprecate TLS1.0 support in emacs) Ted Zlatanov
2017-08-07 1:42 ` common Emacs notifications and alert.el (John W.) package John Wiegley
2017-08-11 13:55 ` Ted Zlatanov
2017-08-15 17:06 ` common Emacs notifications and alert.el (John W.) package (was: Deprecate TLS1.0 support in emacs) Eli Zaretskii
2017-08-15 17:13 ` common Emacs notifications and alert.el (John W.) package John Wiegley
2017-08-04 14:59 ` Deprecate TLS1.0 support in emacs Michael Albinus
2017-08-03 19:39 ` Lars Ingebrigtsen
2017-08-04 21:35 ` Richard Stallman
2017-08-03 19:32 ` Ted Zlatanov
2017-08-04 3:17 ` Stefan Monnier
2017-08-04 13:09 ` Ted Zlatanov
2017-08-04 15:02 ` Lars Ingebrigtsen
2017-08-04 17:29 ` Stefan Monnier
2017-08-07 9:54 ` Robert Pluim
2017-08-10 15:33 ` Ted Zlatanov
2017-08-11 3:15 ` Paul Eggert
2017-08-11 13:53 ` Ted Zlatanov
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=87vam7uxsa.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=rms@gnu.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).