Deprecate TLS1.0 support in emacs

Deprecate TLS1.0 support in emacs

[Robert Pluim]

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

Hi,

whilst investigating another bug, I noticed that
https://lists.gnu.org/ is still using TLS1.0, which is seriously
deprecated. I propose the following patch to make emacs not use TLS1.0
anymore unless explicitly requested (and someone should update the
settings on lists.gnu.org).

Perhaps this warrants a NEWS entry as well, let me know.

Regards

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-TLS1.0-from-default-gnutls-connection-paramet.patch --]
[-- Type: text/x-diff, Size: 2294 bytes --]

From e0526d6ac7a2622a1b8781be4825fbef985a5ed3 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Wed, 12 Jul 2017 14:59:35 +0200
Subject: [PATCH] Remove TLS1.0 from default gnutls connection parameters

        * lisp/net/gnutls.el (gnutls-boot-parameters): Remove TLS1.0
	from default parameters.
	* src/gnutls.c (Fgnutls_boot): Likewise.
---
 lisp/net/gnutls.el | 4 ++--
 src/gnutls.c       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/net/gnutls.el b/lisp/net/gnutls.el
index 5db87329c3..3386dc5efc 100644
--- a/lisp/net/gnutls.el
+++ b/lisp/net/gnutls.el
@@ -264,11 +264,11 @@ gnutls-log-level
         (priority-string (or priority-string
                              (cond
                               ((eq type 'gnutls-anon)
-                               "NORMAL:+ANON-DH:!ARCFOUR-128")
+                               "NORMAL:+ANON-DH:!ARCFOUR-128:-VERS-TLS1.0")
                               ((eq type 'gnutls-x509pki)
                                (if gnutls-algorithm-priority
                                    (upcase gnutls-algorithm-priority)
-                                 "NORMAL")))))
+                                 "NORMAL:-VERS-TLS1.0")))))
         (verify-error (or verify-error
                           ;; this uses the value of `gnutls-verify-error'
                           (cond
diff --git a/src/gnutls.c b/src/gnutls.c
index 2078ad88f2..c3d7f54b73 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -1333,7 +1333,7 @@ PROPLIST is a property list with the following keys:
 
 :hostname is a string naming the remote host.
 
-:priority is a GnuTLS priority string, defaults to "NORMAL".
+:priority is a GnuTLS priority string, defaults to "NORMAL:-VERS-TLS1.0".
 
 :trustfiles is a list of PEM-encoded trust files for `gnutls-x509pki'.
 
@@ -1389,7 +1389,7 @@ one trustfile (usually a CA bundle).  */)
   gnutls_certificate_credentials_t x509_cred = NULL;
   gnutls_anon_client_credentials_t anon_cred = NULL;
   Lisp_Object global_init;
-  char const *priority_string_ptr = "NORMAL"; /* default priority string.  */
+  char const *priority_string_ptr = "NORMAL:-VERS-TLS1.0"; /* default priority string.  */
   char *c_hostname;
 
   /* Placeholders for the property list elements.  */
-- 
2.13.0.rc0

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> whilst investigating another bug, I noticed that
> https://lists.gnu.org/ is still using TLS1.0, which is seriously
> deprecated. I propose the following patch to make emacs not use TLS1.0
> anymore unless explicitly requested (and someone should update the
> settings on lists.gnu.org).

As you point out, removing TLS1.0 support from Emacs will make it
impossible for people to access common resources like
https://lists.gnu.org/ (and many other sites), so I don't think that's a
good idea.

It might make sense to warn people about these resources not being
"secure", though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> whilst investigating another bug, I noticed that
>> https://lists.gnu.org/ is still using TLS1.0, which is seriously
>> deprecated. I propose the following patch to make emacs not use TLS1.0
>> anymore unless explicitly requested (and someone should update the
>> settings on lists.gnu.org).
>
> As you point out, removing TLS1.0 support from Emacs will make it
> impossible for people to access common resources like
> https://lists.gnu.org/ (and many other sites), so I don't think that's a
> good idea.

TLS1.0 is a seriously insecure protocol. I refrained from doing what I
actually wanted to do, which is deprecate TLS1.1 as well. I think it's
a disservice to allow TLS1.0 to continue to be used.

> It might make sense to warn people about these resources not being
> "secure", though.

That could be done with nsm, but only if you'll accept setting the
default network-security-level to 'high, or adding a specific check
for protocol version at 'medium. Option 1 looks something like this:

Warn about TLS1.0 and TLS1.1

	* lisp/net/nsm.el (network-security-level): Change default to
	'high so that we check protocol parameters
	(nsm-check-protocol): Warn if we detect TLS1.0 at level 'high,
	and TLS1.1 at level 'paranoid

diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 8d3463ef0a..f4d1fbb301 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -35,7 +35,7 @@ nsm
   :version "25.1"
   :group 'comm)
 
-(defcustom network-security-level 'medium
+(defcustom network-security-level 'high
   "How secure the network should be.
 If a potential problem with the security of the network
 connection is found, the user is asked to give input into how the
@@ -231,6 +231,27 @@ nsm-check-protocol
 	     host port protocol)))
       (delete-process process)
       nil)
+     ((and protocol
+	   (string-match "TLS1.0" protocol)
+	   (not (memq :tls1.0 (plist-get settings :conditions)))
+	   (not
+	    (nsm-query
+	     host port status :tls1.0
+	     "The connection to %s:%s uses the %s protocol, which is unsafe."
+	     host port protocol)))
+      (delete-process process)
+      nil)
+     ((and protocol
+           (eq network-security-level 'paranoid)
+	   (string-match "TLS1.1" protocol)
+	   (not (memq :tls1.0 (plist-get settings :conditions)))
+	   (not
+	    (nsm-query
+	     host port status :tls1.1
+	     "The connection to %s:%s uses the %s protocol, which is unsafe."
+	     host port protocol)))
+      (delete-process process)
+      nil)
      (t
       process))))
 

Re: Deprecate TLS1.0 support in emacs

[Andreas Schwab]

On Jul 12 2017, Robert Pluim <rpluim@gmail.com> wrote:

> @@ -231,6 +231,27 @@ nsm-check-protocol
>  	     host port protocol)))
>        (delete-process process)
>        nil)
> +     ((and protocol
> +	   (string-match "TLS1.0" protocol)
> +	   (not (memq :tls1.0 (plist-get settings :conditions)))
> +	   (not
> +	    (nsm-query
> +	     host port status :tls1.0
> +	     "The connection to %s:%s uses the %s protocol, which is unsafe."
> +	     host port protocol)))
> +      (delete-process process)
> +      nil)
> +     ((and protocol
> +           (eq network-security-level 'paranoid)
> +	   (string-match "TLS1.1" protocol)

Why string-match?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Andreas Schwab <schwab@suse.de> writes:

> On Jul 12 2017, Robert Pluim <rpluim@gmail.com> wrote:
>
>> @@ -231,6 +231,27 @@ nsm-check-protocol
>>  	     host port protocol)))
>>        (delete-process process)
>>        nil)
>> +     ((and protocol
>> +	   (string-match "TLS1.0" protocol)
>> +	   (not (memq :tls1.0 (plist-get settings :conditions)))
>> +	   (not
>> +	    (nsm-query
>> +	     host port status :tls1.0
>> +	     "The connection to %s:%s uses the %s protocol, which is unsafe."
>> +	     host port protocol)))
>> +      (delete-process process)
>> +      nil)
>> +     ((and protocol
>> +           (eq network-security-level 'paranoid)
>> +	   (string-match "TLS1.1" protocol)
>
> Why string-match?

It's what the surrounding code uses to check for ssl. You'd prefer
string-equal ?

Robert

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> TLS1.0 is a seriously insecure protocol. I refrained from doing what I
> actually wanted to do, which is deprecate TLS1.1 as well. I think it's
> a disservice to allow TLS1.0 to continue to be used.

It's no more "insecure" to read lists.gnu.org via HTTPS than it is via
HTTP, which is also an option.  Denying the former while allowing the
latter is rather nonsensical.

And if it had been available only via HTTPS, then refusing Emacs users
to access it would also have a security impact: Refusing access to
information is not "security", but the opposite.

> That could be done with nsm, but only if you'll accept setting the
> default network-security-level to 'high, or adding a specific check
> for protocol version at 'medium. Option 1 looks something like this:

No, `high' should be reserved for people that want higher than normal
network security.

It might make sense to warn for TLS1.0 on `medium', though, but I'd have
to check what other web browsers do here.  I think, for instance, that
Firefox still supports TLS1.0, and gives no warning, either.  So unless
I've misunderstood the Firefox situation, I don't think we should do
anything here.

More long-term, I think it may make sense to just treat these "insecure"
protocols as if they were unencrypted, user interface wise, but that
would be up to each individual application (eww, package-list, etc) and
not further down in the network stack?  Perhaps?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Andreas Schwab]

On Jul 12 2017, Robert Pluim <rpluim@gmail.com> wrote:

> Andreas Schwab <schwab@suse.de> writes:
>
>> On Jul 12 2017, Robert Pluim <rpluim@gmail.com> wrote:
>>
>>> @@ -231,6 +231,27 @@ nsm-check-protocol
>>>  	     host port protocol)))
>>>        (delete-process process)
>>>        nil)
>>> +     ((and protocol
>>> +	   (string-match "TLS1.0" protocol)
>>> +	   (not (memq :tls1.0 (plist-get settings :conditions)))
>>> +	   (not
>>> +	    (nsm-query
>>> +	     host port status :tls1.0
>>> +	     "The connection to %s:%s uses the %s protocol, which is unsafe."
>>> +	     host port protocol)))
>>> +      (delete-process process)
>>> +      nil)
>>> +     ((and protocol
>>> +           (eq network-security-level 'paranoid)
>>> +	   (string-match "TLS1.1" protocol)
>>
>> Why string-match?
>
> It's what the surrounding code uses to check for ssl. You'd prefer
> string-equal ?

Is TLS1.10 or TLS101 unsafe?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Andreas Schwab <schwab@suse.de> writes:

>
> Is TLS1.10 or TLS101 unsafe?

Good point. The next version will be better.

Robert

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> TLS1.0 is a seriously insecure protocol. I refrained from doing what I
>> actually wanted to do, which is deprecate TLS1.1 as well. I think it's
>> a disservice to allow TLS1.0 to continue to be used.
>
> It's no more "insecure" to read lists.gnu.org via HTTPS than it is via
> HTTP, which is also an option.  Denying the former while allowing the
> latter is rather nonsensical.

This is not about reading lists.gnu.org specifically, this is about
all TLS protocol use from emacs. That should not use protocols that
contain known serious security flaws if we can avoid it. When you
choose to use https you have an expectation of security, unlike with
http, so we should attempt to fulfill that expectation.

> And if it had been available only via HTTPS, then refusing Emacs users
> to access it would also have a security impact: Refusing access to
> information is not "security", but the opposite.

There is no refusal of access, just refusal of a specific protocol. If
we implement your suggestion from below there won't even be refusal.

>> That could be done with nsm, but only if you'll accept setting the
>> default network-security-level to 'high, or adding a specific check
>> for protocol version at 'medium. Option 1 looks something like this:
>
> No, `high' should be reserved for people that want higher than normal
> network security.

OK, then we should integrate a check like this into `medium'. TLS1.0
should be warned about in the default configuration. I'd argue that
TLS1.1 should be as well, but we can always revisit that later.

I'll see if I can come up with a patch tomorrow.

> It might make sense to warn for TLS1.0 on `medium', though, but I'd have
> to check what other web browsers do here.  I think, for instance, that
> Firefox still supports TLS1.0, and gives no warning, either.  So unless
> I've misunderstood the Firefox situation, I don't think we should do
> anything here.

Firefox still allows TLS1.0, unless you configure it in paranoid mode,
like yours truly.

> More long-term, I think it may make sense to just treat these "insecure"
> protocols as if they were unencrypted, user interface wise, but that
> would be up to each individual application (eww, package-list, etc) and
> not further down in the network stack?  Perhaps?

No, we should just attempt to eradicate the use of TLS1.0 (and
TLS1.1), not allow people to keep using them :-)

I appreciate that's a strong opinion, but I definitely think we should
strongly encourage people to move away from both of these protocols.

Robert

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> There is no refusal of access, just refusal of a specific protocol. If
> we implement your suggestion from below there won't even be refusal.

It is a refusal to access a resource because somebody has determined
that a specific protocol (HTTP + TLS1.0) is something that our users
shouldn't be able to use.

lists.gnu.org is, of course, just one example.

> I appreciate that's a strong opinion, but I definitely think we should
> strongly encourage people to move away from both of these protocols.

Encouragement is fine, but making our users switch to Firefox because of
this obsession with protocols isn't.

As more and more resources are being made available over encrypted
channels only, and as more and more of these (as a result of bad
maintenance and the like) get tagged as "invalid encryption", something
has to give.

It seems like the current movement is to just to start ignoring whether
protocols are outdated, use invalid certificates and the like, and just
tell the user "you tried to access this via a secure channel.  It's not,
but here's the content anyway".

I may be misremembering, but I think the new Chrome beta is going in
this direction: No explicit refusals to access anything, but just a big
red X in the menu bar saying "UNSAFE".  It is, you know, not less safe
than accessing via an unencrypted channel.

I think this is probably the way Emacs should consider moving, too, for
eww and package-list.  For other use, we may consider having the NSM
prompt the user for what to do with TLS1.0.  But probably not just yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> There is no refusal of access, just refusal of a specific protocol. If
>> we implement your suggestion from below there won't even be refusal.
>
> It is a refusal to access a resource because somebody has determined
> that a specific protocol (HTTP + TLS1.0) is something that our users
> shouldn't be able to use.

Allright. If we implement the checking in nsm, then that becomes
"something our users get warned about but can be overriden, don't
complain to us afterwards".

> lists.gnu.org is, of course, just one example.
>
>> I appreciate that's a strong opinion, but I definitely think we should
>> strongly encourage people to move away from both of these protocols.
>
> Encouragement is fine, but making our users switch to Firefox because of
> this obsession with protocols isn't.

We have no choice about it. People with bad intentions obsess over
protocols far more than this. We should attempt to make their lives as
hard as possible.

> As more and more resources are being made available over encrypted
> channels only, and as more and more of these (as a result of bad
> maintenance and the like) get tagged as "invalid encryption", something
> has to give.
>
> It seems like the current movement is to just to start ignoring whether
> protocols are outdated, use invalid certificates and the like, and just
> tell the user "you tried to access this via a secure channel.  It's not,
> but here's the content anyway".

I happen to disagree with that movement, but if that's what you want
emacs to do it's possible.

> I may be misremembering, but I think the new Chrome beta is going in
> this direction: No explicit refusals to access anything, but just a big
> red X in the menu bar saying "UNSAFE".  It is, you know, not less safe
> than accessing via an unencrypted channel.

It's less safe because some people won't notice the 'UNSAFE'
indication, and will be unpleasantly surprised when things they
thought were encrypted in transit aren't. Hence my preference for the
prescriptive stance of banning TLS1.0 and TLS1.1

> I think this is probably the way Emacs should consider moving, too, for
> eww and package-list.  For other use, we may consider having the NSM
> prompt the user for what to do with TLS1.0.  But probably not just yet.

OK. I'll just patch my emacs locally to disable TLS1.0 and TLS1.1
until then.

At some point we should deprecate lisp/net/tls.el as well (or as a
bare minimum remove its support for ssl), the builtin TLS support
works very well.

Robert

Re: Deprecate TLS1.0 support in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It is a refusal to access a resource because somebody has determined
  > that a specific protocol (HTTP + TLS1.0) is something that our users
  > shouldn't be able to use.

I agree -- our software should not absolutely refuse to communicate
a way that we judge risky.  We should explain the situation and state
how to enable that method (perhaps with a user option).

  > tell the user "you tried to access this via a secure channel.  It's not,
  > but here's the ... anyway".

I agree.

  > but here's the content anyway".

Please don't use the word "content" to refer to works or publications.
The term disparages all publications.
See https://gnu.org/philosophy/words-to-avoid.html.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

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

Richard Stallman <rms@gnu.org> writes:

>   > It is a refusal to access a resource because somebody has determined
>   > that a specific protocol (HTTP + TLS1.0) is something that our users
>   > shouldn't be able to use.
>
> I agree -- our software should not absolutely refuse to communicate
> a way that we judge risky.  We should explain the situation and state
> how to enable that method (perhaps with a user option).
>

OK. NSM provides the requisite infrastructure for that already, we
just have to enable some more checking. Here's an initial patch, we
can now decide exactly which checks we should do at medium security
level, and update the manuals. Personally I feel we should warn for
ssl, tls1.0, tls1.1, RC4, and SHA1. Diffie-Hellman I'm not too sure
about, although I'll note that Google Chrome switched to 1024 bits two
years ago.

Regards

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Check-for-SSL-TLS1.0-and-TLS1.1-and-warn-user.patch --]
[-- Type: text/x-diff, Size: 4611 bytes --]

From 6587993f682544fa2314a0d41101274a1c004ab5 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Thu, 13 Jul 2017 15:06:07 +0200
Subject: [PATCH] Check for SSL, TLS1.0 and TLS1.1 and warn user

* lisp/net/nsm.el (nsm-check-tls-connection): Check protocol
 parameters at the default `medium' security level
 (nsm-check-for-deprecated-protocols): New function. Abstract
 protocol version checks out of nsm-check-protocols and check for
 TLS1.0 and TLS1.1
 (nsm-check-protocol): Use it
* etc/NEWS (libraries): Document the change in tls connection
  behaviour
---
 etc/NEWS        |  7 +++++++
 lisp/net/nsm.el | 40 +++++++++++++++++++++++++++-------------
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index a00760c2f8..1880847048 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -459,6 +459,13 @@ Linum mode and all similar packages are henceforth becoming obsolete.
 Users and developers are encouraged to switch to this new feature
 instead.
 
+** Network connections which use ssl, tls1.0 or tls1.1 will now be
+warned about by the network security manager. The user will be
+prompted to allow/disallow the connection on a per-connection/per-host
+basis.  These 3 protocols have myriad proven exploits against them and
+should be avoided whenever possible.  Set network-security-level to
+'low' to disable these new checks.
+
 \f
 * Editing Changes in Emacs 26.1
 
diff --git a/lisp/net/nsm.el b/lisp/net/nsm.el
index 8d3463ef0a..03670957a5 100644
--- a/lisp/net/nsm.el
+++ b/lisp/net/nsm.el
@@ -120,8 +120,8 @@ nsm-verify-connection
 (defun nsm-check-tls-connection (process host port status settings)
   (let ((process (nsm-check-certificate process host port status settings)))
     (if (and process
-	     (>= (nsm-level network-security-level) (nsm-level 'high)))
-	;; Do further protocol-level checks if the security is high.
+	     (>= (nsm-level network-security-level) (nsm-level 'medium)))
+	;; Do further protocol-level checks if the security is medium.
 	(nsm-check-protocol process host port status settings)
       process)))
 
@@ -199,7 +199,7 @@ nsm-check-protocol
 	   (not
 	    (nsm-query
 	     host port status :diffie-hellman-prime-bits
-	     "The Diffie-Hellman prime bits (%s) used for this connection to %s:%s is less than what is considered safe (%s)."
+	     "The Diffie-Hellman prime bits (%s) used for this connection to %s:%s is less than what is considered safe (%s). Accept at your own risk."
 	     prime-bits host port 1024)))
       (delete-process process)
       nil)
@@ -208,7 +208,7 @@ nsm-check-protocol
 	   (not
 	    (nsm-query
 	     host port status :rc4
-	     "The connection to %s:%s uses the RC4 algorithm (%s), which is believed to be unsafe."
+	     "The connection to %s:%s uses the RC4 algorithm (%s), which is unsafe. Accept at your own risk."
 	     host port encryption)))
       (delete-process process)
       nil)
@@ -217,23 +217,37 @@ nsm-check-protocol
 	   (not
 	    (nsm-query
 	     host port status :signature-sha1
-	     "The certificate used to verify the connection to %s:%s uses the SHA1 algorithm (%s), which is believed to be unsafe."
+	     "The certificate used to verify the connection to %s:%s uses the SHA1 algorithm (%s), which is unsafe. Accept at your own risk."
 	     host port signature-algorithm)))
       (delete-process process)
       nil)
-     ((and protocol
-	   (string-match "SSL" protocol)
-	   (not (memq :ssl (plist-get settings :conditions)))
-	   (not
-	    (nsm-query
-	     host port status :ssl
-	     "The connection to %s:%s uses the %s protocol, which is believed to be unsafe."
-	     host port protocol)))
+     ((let ((what (nsm-check-for-deprecated-protocols protocol settings)))
+        (and protocol
+             what
+	     (not
+	      (nsm-query
+	       host port status what
+	       "The connection to %s:%s uses the %s protocol, which is unsafe. Accept at your own risk."
+	       host port protocol))))
       (delete-process process)
       nil)
      (t
       process))))
 
+(defun nsm-check-for-deprecated-protocols (protocol settings)
+  (cond
+   ((and (string-match "SSL" protocol)
+         (not (memq :ssl (plist-get settings :conditions))))
+    :ssl)
+   ((and (string-equal "TLS1.0" protocol)
+         (not (memq :tls1.0 (plist-get settings :conditions))))
+    :tls1.0)
+   ((and (string-equal "TLS1.1" protocol)
+         (not (memq :tls1.1 (plist-get settings :conditions))))
+    :tls1.1)
+   (t
+    nil)))
+
 (defun nsm-fingerprint (status)
   (plist-get (plist-get status :certificate) :public-key-id))
 
-- 
2.13.0.rc0

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I agree -- our software should not absolutely refuse to communicate
>> a way that we judge risky.  We should explain the situation and state
>> how to enable that method (perhaps with a user option).
>>
>
> OK. NSM provides the requisite infrastructure for that already, we
> just have to enable some more checking. Here's an initial patch, we
> can now decide exactly which checks we should do at medium security
> level, and update the manuals. Personally I feel we should warn for
> ssl, tls1.0, tls1.1, RC4, and SHA1. Diffie-Hellman I'm not too sure
> about, although I'll note that Google Chrome switched to 1024 bits two
> years ago.

Ping? I'd like to improve the default communication security settings
of Emacs, the current state is too insecure for my liking.

Regards

Robert

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Ping? I'd like to improve the default communication security settings
> of Emacs, the current state is too insecure for my liking.

My feeling, as I think I said, is that it's premature to warn about
things like TLS1.0 in an intrusive manner.  There's too many sites out
there that still use that protocol, and warning too much is no help for
our users.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Ping? I'd like to improve the default communication security settings
>> of Emacs, the current state is too insecure for my liking.
>
> My feeling, as I think I said, is that it's premature to warn about
> things like TLS1.0 in an intrusive manner.  There's too many sites out
> there that still use that protocol, and warning too much is no help for
> our users.

There are still many sites like that, but if we don't warn people
about them, there will never be any pressure on their owners to
upgrade to TLS1.2, or stop using SHA-1, or increase DH key size.

How about warning as in my patch, but only at network-security-level
>= high? And revisit the level later?

Regards

Robert

Re: Deprecate TLS1.0 support in emacs

[Paul Eggert]

Lars Ingebrigtsen wrote:
> it's premature to warn about
> things like TLS1.0 in an intrusive manner.  There's too many sites out
> there that still use that protocol, and warning too much is no help for
> our users

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.

For what it's worth, I surf the web mostly via Firefox configured to use only 
TLS v1.1 or higher, which is stricter than what's being proposed for Emacs. Only 
once in the last month did I run into problems with this - it was an older 
internal UCLA website that hadn't been upgraded, and which upgraded immediately 
after I notified its administrators.  So at least for me, a warning from Emacs 
would have been more helpful, had I been using Emacs.

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

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.

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

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

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

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

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

Could we replace the prompt with a simple message (and if the message
gets overwritten too soon, maybe adding a short delay)?


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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.
>
> Could we replace the prompt with a simple message (and if the message
> gets overwritten too soon, maybe adding a short delay)?

Hm...  that sounds like a nice compromise.  However, there might be a
lot of these messages if, for instance, the user visits a web page where
all the images are being served over a TLS connection we're warning
about.

Or perhaps warnings in those instances should be inhibited?

Anyway, the NSM layer could be easily extended to add certain
notifications to each security level.  So you'd get something like

"Connection to fsf.org:443 is less secure because of an old TLS version"

or along those lines flashing in the minibuffer...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

> Hm...  that sounds like a nice compromise.  However, there might be a
> lot of these messages if, for instance, the user visits a web page where
> all the images are being served over a TLS connection we're warning
> about.

This problem keeps occurring, so we simply need to solve it once an for
all: provide a new variant of `message` which OT1H guarantees that this
message will be visible for a minimum of N seconds, and OTOH
guarantees that it won't be repeated more than once every M seconds (M
being probably large enough to be counted in hours).


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Thu, 03 Aug 2017 11:52:45 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> Hm...  that sounds like a nice compromise.  However, there might be a
>> lot of these messages if, for instance, the user visits a web page where
>> all the images are being served over a TLS connection we're warning
>> about.

SM> This problem keeps occurring, so we simply need to solve it once an for
SM> all: provide a new variant of `message` which OT1H guarantees that this
SM> message will be visible for a minimum of N seconds, and OTOH
SM> guarantees that it won't be repeated more than once every M seconds (M
SM> being probably large enough to be counted in hours).

I'd love that. I think the `notifications-notify' function would be a
good delegate on platforms that support it, and a suitable fallback could
be developed for the rest of the platforms.

Ted

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Tue, 01 Aug 2017 13:56:02 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

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

SM> Could we replace the prompt with a simple message (and if the message
SM> gets overwritten too soon, maybe adding a short delay)?

IMHO, this replacement is OK only if the message has buttons to take the
appropriate actions (including silencing warnings as needed). Otherwise
it's noise users will filter out.

Ted

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> This problem keeps occurring, so we simply need to solve it once an for
> all: provide a new variant of `message` which OT1H guarantees that this
> message will be visible for a minimum of N seconds, and OTOH
> guarantees that it won't be repeated more than once every M seconds (M
> being probably large enough to be counted in hours).

Yes, that would be very nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

> IMHO, this replacement is OK only if the message has buttons to take the
> appropriate actions (including silencing warnings as needed).  Otherwise
> it's noise users will filter out.

I generally agree on the principle, but at the same time I wonder what
actions would make sense: there are basically 2 applicable actions, one
of which (contact the webmaster to suggest upgrading to a better
protocol) is difficult to automate.

As for the other action (silence the warning) I wonder if it's really
needed: if the mechanism is discreet enough, it's just as easy for the
user to "filter it out as noise".


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 03 Aug 2017 15:30:42 -0400
> 
> SM> This problem keeps occurring, so we simply need to solve it once an for
> SM> all: provide a new variant of `message` which OT1H guarantees that this
> SM> message will be visible for a minimum of N seconds, and OTOH
> SM> guarantees that it won't be repeated more than once every M seconds (M
> SM> being probably large enough to be counted in hours).
> 
> I'd love that. I think the `notifications-notify' function would be a
> good delegate on platforms that support it, and a suitable fallback could
> be developed for the rest of the platforms.

notifications-notify only works in GUI sessions, so TTY sessions will
need a fallback that will probably still use the echo area.

Personally, I don't think notifications-notify is suitable for this
even in GUI sessions, but that's me.

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Thu, 03 Aug 2017 23:17:13 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> IMHO, this replacement is OK only if the message has buttons to take the
>> appropriate actions (including silencing warnings as needed).  Otherwise
>> it's noise users will filter out.

SM> I generally agree on the principle, but at the same time I wonder what
SM> actions would make sense: there are basically 2 applicable actions, one
SM> of which (contact the webmaster to suggest upgrading to a better
SM> protocol) is difficult to automate.

I would suggest these possible actions:

* don't warn me about this site anymore and proceed (whitelist)
* don't warn me about TLS 1.0 issues for (dropdown: 1 day, 3 days, 1 month)
* don't warn me about this site for (dropdown: 1 day, 3 days, 1 month)
* proceed this once
* blacklist site as long as it uses TLS1.0; abort connection; never notify
* blacklist TLS1.0 globally; abort all such connections; never notify

SM> As for the other action (silence the warning) I wonder if it's really
SM> needed: if the mechanism is discreet enough, it's just as easy for the
SM> user to "filter it out as noise".

Sorry, I don't understand what you mean.

Ted

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Fri, 04 Aug 2017 08:40:40 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 03 Aug 2017 15:30:42 -0400
>> 
>> I'd love that. I think the `notifications-notify' function would be a
>> good delegate on platforms that support it, and a suitable fallback could
>> be developed for the rest of the platforms.

EZ> notifications-notify only works in GUI sessions, so TTY sessions will
EZ> need a fallback that will probably still use the echo area.

Right. I would implement the fallback inside `notifications-notify' and
let the user customize that, so Emacs can have a central dispatcher for
general notifications (as opposed to log messages).

Most graphical platform have a desktop-level notification system that's
familiar to users, so plugging into that instead of inventing something
new would make sense.

EZ> Personally, I don't think notifications-notify is suitable for this
EZ> even in GUI sessions, but that's me.

Can you explain why it's not? Behavior, capabilities, GUI-only,
something else?

Ted

Re: Deprecate TLS1.0 support in emacs

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 04 Aug 2017 09:13:56 -0400
> 
> EZ> Personally, I don't think notifications-notify is suitable for this
> EZ> even in GUI sessions, but that's me.
> 
> Can you explain why it's not? Behavior, capabilities, GUI-only,
> something else?

IMO, it isn't right to display notifications there from a program that
runs in the foreground.  Too far from user eyes, too.

Re: Deprecate TLS1.0 support in emacs

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Right. I would implement the fallback inside `notifications-notify' and
> let the user customize that, so Emacs can have a central dispatcher for
> general notifications (as opposed to log messages).

Please not in `notifications-notify', this function has a defined
scope. There are packages which provide a broader notification
interface, like sauron <https://github.com/djcb/sauron/blob/master/README.org>.

And in core Emacs, `notifications-notify' is also used in different
packages, like erc/erc-desktop-notifications.el, org/org-clock.el, and
gnus/gnus-notifications.el.

> Ted

Best regards, Michael.

Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I would suggest these possible actions:
>
> * don't warn me about this site anymore and proceed (whitelist)
> * don't warn me about TLS 1.0 issues for (dropdown: 1 day, 3 days, 1 month)
> * don't warn me about this site for (dropdown: 1 day, 3 days, 1 month)
> * proceed this once
> * blacklist site as long as it uses TLS1.0; abort connection; never notify
> * blacklist TLS1.0 globally; abort all such connections; never notify

But this is approximately what the NSM does now...  Or do you mean that
the message in the echo area should be clickable, and that would bring
up the normal NSM dialogue?

That's would be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

> IMO, it isn't right to display notifications there from a program that
> runs in the foreground.  Too far from user eyes, too.

Agreed.  This functionality is for use when Emacs wants to notify the
user about something happening elsewhere than where the user is
currently focused.


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

SM> As for the other action (silence the warning) I wonder if it's really
SM> needed: if the mechanism is discreet enough, it's just as easy for the
SM> user to "filter it out as noise".

> Sorry, I don't understand what you mean.

That if the user feels so bothered by the warning to want 6 different
choices (with 3 additional sub-choices for some of them), then we
already failed because the user is already annoyed.

Instead I think that the warning should be just sufficiently visible
that the user who's interested will notice it, but sufficiently
unobtrusive that the user who doesn't care can just "filter out".


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Fri, 04 Aug 2017 13:26:29 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

> On Fri, 04 Aug 2017 17:51:28 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 
>> IMO, it isn't right to display notifications there from a program that
>> runs in the foreground.  Too far from user eyes, too.

SM> Agreed.  This functionality is for use when Emacs wants to notify the
SM> user about something happening elsewhere than where the user is
SM> currently focused.

I respectfully disagree. Notifications don't have an implicit user
attention scope. They are posted no matter where the user is focused,
typically in a globally shared area of the screen to make them easy to
notice and consistent in appearance.

On Fri, 04 Aug 2017 17:02:45 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I would suggest these possible actions:
>> 
>> * don't warn me about this site anymore and proceed (whitelist)
>> * don't warn me about TLS 1.0 issues for (dropdown: 1 day, 3 days, 1 month)
>> * don't warn me about this site for (dropdown: 1 day, 3 days, 1 month)
>> * proceed this once
>> * blacklist site as long as it uses TLS1.0; abort connection; never notify
>> * blacklist TLS1.0 globally; abort all such connections; never notify

LI> But this is approximately what the NSM does now...  Or do you mean that
LI> the message in the echo area should be clickable, and that would bring
LI> up the normal NSM dialogue?

That's what I mean, yeah :) We're just doing the user interaction in a
modeless transient window instead of a modal dialog that disrupts the
user experience. Is that possible?

On Fri, 04 Aug 2017 16:59:00 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Right. I would implement the fallback inside `notifications-notify' and
>> let the user customize that, so Emacs can have a central dispatcher for
>> general notifications (as opposed to log messages).

MA> Please not in `notifications-notify', this function has a defined
MA> scope. There are packages which provide a broader notification
MA> interface, like sauron <https://github.com/djcb/sauron/blob/master/README.org>.

...but nothing in Emacs does :) That's sort of where I was going.

Do we write our own? Could we use notifications.el and add new functions
there? Do we try to add sauron to the core?

On Fri, 04 Aug 2017 13:29:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> As for the other action (silence the warning) I wonder if it's really
SM> needed: if the mechanism is discreet enough, it's just as easy for the
SM> user to "filter it out as noise".

>> Sorry, I don't understand what you mean.

SM> if the user feels so bothered by the warning to want 6 different
SM> choices (with 3 additional sub-choices for some of them), then we
SM> already failed because the user is already annoyed.

Those choices I proposed would be in a modeless notification window, not
in a modal dialog. So there is much less friction and distraction.

SM> Instead I think that the warning should be just sufficiently visible
SM> that the user who's interested will notice it, but sufficiently
SM> unobtrusive that the user who doesn't care can just "filter out".

That's a good goal, and offering choices in a transient notification
window is in line with it.

Ted

Re: Deprecate TLS1.0 support in emacs

[Stefan Monnier]

>>> IMO, it isn't right to display notifications there from a program that
>>> runs in the foreground.  Too far from user eyes, too.
SM> Agreed.  This functionality is for use when Emacs wants to notify the
SM> user about something happening elsewhere than where the user is
SM> currently focused.
> I respectfully disagree. Notifications don't have an implicit user
> attention scope. They are posted no matter where the user is focused,
> typically in a globally shared area of the screen to make them easy to
> notice and consistent in appearance.

But exactly because it's posted in a area independent from the current
focus, it makes it rather undesirable to use it for something that is
currently in focus.

Can you give me examples where this notification area is used by other
programs for something related to the current user's action?  In my
experience, in such situations they'll rather use something like
a tooltip, a dialog box, or some message shown within the application's
own window.


        Stefan

Re: Deprecate TLS1.0 support in emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This problem keeps occurring, so we simply need to solve it once an for
  > all: provide a new variant of `message` which OT1H guarantees that this
  > message will be visible for a minimum of N seconds, and OTOH
  > guarantees that it won't be repeated more than once every M seconds (M
  > being probably large enough to be counted in hours).

Should M and N be specified in the call, or should they be global
parameters?  I think the latter is better.

I suggest defining a function 'hint-message' which displays a message
this way, or various appropriate ways to serve this kind of goal.

If we find that there are multiple classes of hint messages that should be
treated somewhat differently, we could make multiple such functions.
That would be better than encouraging each package to come up with its
own M and N.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Fri, 04 Aug 2017 17:21:56 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> IMO, it isn't right to display notifications there from a program that
>>>> runs in the foreground.  Too far from user eyes, too.
SM> Agreed.  This functionality is for use when Emacs wants to notify the
SM> user about something happening elsewhere than where the user is
SM> currently focused.
>> I respectfully disagree. Notifications don't have an implicit user
>> attention scope. They are posted no matter where the user is focused,
>> typically in a globally shared area of the screen to make them easy to
>> notice and consistent in appearance.

SM> But exactly because it's posted in a area independent from the current
SM> focus, it makes it rather undesirable to use it for something that is
SM> currently in focus.

You're right, I see your point.

Would it be acceptable to use the system notifications now, and start a
bigger effort to provide an Emacs-native, focus-aware notification
system? Or do you think such a system is easy enough that an
intermediate stage is just not needed?

SM> Can you give me examples where this notification area is used by other
SM> programs for something related to the current user's action?  In my
SM> experience, in such situations they'll rather use something like
SM> a tooltip, a dialog box, or some message shown within the application's
SM> own window.

I've seen it done for background actions that the user initiated. But
you're right that typically this is inside the application. I was
thinking of more generic notifications that are not bound to the user's
attention scope.

Ted

Re: Deprecate TLS1.0 support in emacs

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MA> Please not in `notifications-notify', this function has a defined
> MA> scope. There are packages which provide a broader notification
> MA> interface, like sauron
> MA> <https://github.com/djcb/sauron/blob/master/README.org>.
>
> ...but nothing in Emacs does :) That's sort of where I was going.
>
> Do we write our own? Could we use notifications.el and add new functions
> there? Do we try to add sauron to the core?

I believe a common notification package, on top of notifications.el,
would serve. It could be sauron.el, it could be something else.

notifications.el is biased to D-Bus. We shouldn't bore other platforms,
which do not support D-Bus, with this.

> Ted

Best regards, Michael.

common Emacs notifications and alert.el (John W.) package (was: Deprecate TLS1.0 support in emacs)

[Ted Zlatanov]

On Sat, 05 Aug 2017 09:21:37 +0200 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
MA> Please not in `notifications-notify', this function has a defined
MA> scope. There are packages which provide a broader notification
MA> interface, like sauron
MA> <https://github.com/djcb/sauron/blob/master/README.org>.
>> 
>> ...but nothing in Emacs does :) That's sort of where I was going.
>> 
>> Do we write our own? Could we use notifications.el and add new functions
>> there? Do we try to add sauron to the core?

MA> I believe a common notification package, on top of notifications.el,
MA> would serve. It could be sauron.el, it could be something else.

MA> notifications.el is biased to D-Bus. We shouldn't bore other platforms,
MA> which do not support D-Bus, with this.

A while ago I proposed to John Wiegley to use his
https://github.com/jwiegley/alert package. This thread reminded me of
that request. It seems perfect for the use cases discussed in the parent
thread.

Can we start the process on including alert.el?

Ted

Re: common Emacs notifications and alert.el (John W.) package

[John Wiegley]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> A while ago I proposed to John Wiegley to use his
TZ> https://github.com/jwiegley/alert package. This thread reminded me of
TZ> that request. It seems perfect for the use cases discussed in the parent
TZ> thread.

TZ> Can we start the process on including alert.el?

I'd be happy to starting working on that later this week. I've just needed
the impulse to finish the legal aspects.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Deprecate TLS1.0 support in emacs

[Robert Pluim]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 03 Aug 2017 23:17:13 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
> SM> I generally agree on the principle, but at the same time I wonder what
> SM> actions would make sense: there are basically 2 applicable actions, one
> SM> of which (contact the webmaster to suggest upgrading to a better
> SM> protocol) is difficult to automate.
>
> I would suggest these possible actions:
>
> * don't warn me about this site anymore and proceed (whitelist)
> * don't warn me about TLS 1.0 issues for (dropdown: 1 day, 3 days, 1 month)
> * don't warn me about this site for (dropdown: 1 day, 3 days, 1
> month)

I don't think I'd ever want this to be time-based. For me it's all
subsumed by this one:

> * proceed this once

since I'll want to revisit my decision the next time I connect,
whenever that is.

> * blacklist site as long as it uses TLS1.0; abort connection; never notify
> * blacklist TLS1.0 globally; abort all such connections; never notify

These seem a little drastic, even to me :-) You can achieve almost
this already by customizing gnutls-algorithm-priority

BTW, Debian unstable just started the process of removing support for
TLS1.0 *and* TLS1.1 from OpenSSL, I assume the equivalent GnuTLS
change is not far behind:

https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html

Regards

Robert

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Mon, 07 Aug 2017 11:54:22 +0200 Robert Pluim <rpluim@gmail.com> wrote: 

RP> BTW, Debian unstable just started the process of removing support for
RP> TLS1.0 *and* TLS1.1 from OpenSSL, I assume the equivalent GnuTLS
RP> change is not far behind:

RP> https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html

Thanks for that information. We'll have to make sure our side is
flexible and making these adjustments in the future is not a lot of
work.

Ted

Re: Deprecate TLS1.0 support in emacs

[Paul Eggert]

Ted Zlatanov wrote:
> RP>https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html
> 
> ... We'll have to make sure our side is
> flexible and making these adjustments in the future is not a lot of
> work.

This will not require any adjustments to Emacs source code, right? I don't see 
anything in Emacs that requires the Gnutls library to support older TLS versions.

Re: Deprecate TLS1.0 support in emacs

[Ted Zlatanov]

On Thu, 10 Aug 2017 20:15:08 -0700 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> Ted Zlatanov wrote:
RP> https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html
>> 
>> ... We'll have to make sure our side is
>> flexible and making these adjustments in the future is not a lot of
>> work.

PE> This will not require any adjustments to Emacs source code, right? I don't see
PE> anything in Emacs that requires the Gnutls library to support older TLS
PE> versions.

Correct, but we spent time and effort talking about the UI around
deprecating TLS1.0, and it will have to be implemented (possibly with
alert.el if John gets around to merging it).

Ted

Re: common Emacs notifications and alert.el (John W.) package

[Ted Zlatanov]

On Sun, 06 Aug 2017 18:42:01 -0700 John Wiegley <jwiegley@gmail.com> wrote: 

>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> A while ago I proposed to John Wiegley to use his
TZ> https://github.com/jwiegley/alert package. This thread reminded me of
TZ> that request. It seems perfect for the use cases discussed in the parent
TZ> thread.

TZ> Can we start the process on including alert.el?

JW> I'd be happy to starting working on that later this week. I've just needed
JW> the impulse to finish the legal aspects.

That would be really great in the core, so the TLS1.0 deprecation
notices and possibly the NSM as a whole could use it by default. I'm
sure other packages will jump on it too :)

Thanks
Ted

Re: common Emacs notifications and alert.el (John W.) package (was: Deprecate TLS1.0 support in emacs)

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sun, 06 Aug 2017 15:17:34 -0400
> 
> A while ago I proposed to John Wiegley to use his
> https://github.com/jwiegley/alert package. This thread reminded me of
> that request. It seems perfect for the use cases discussed in the parent
> thread.
> 
> Can we start the process on including alert.el?

IMO, before we include alert.el and make it a dependency of the likes
of NSM, we should make sure alert.el supports all of the currently
supported platforms.  AFAIK, at least MS-Windows isn't supported,
although we have w32-notification-notify since Emacs 25.  Apologies if
I missed something.

Re: common Emacs notifications and alert.el (John W.) package

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> IMO, before we include alert.el and make it a dependency of the likes of
> NSM, we should make sure alert.el supports all of the currently supported
> platforms. AFAIK, at least MS-Windows isn't supported, although we have
> w32-notification-notify since Emacs 25. Apologies if I missed something.

You're quite right Eli, this is a prerequisite.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2