GNU bug report logs - #19284
25.0.50; tls.el uses option --insecure

Previous Next

Full log

View this message in rfc822 format

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19284 <at> debbugs.gnu.org
Subject: bug#19284: 25.0.50; tls.el uses option --insecure 
Date: Wed, 30 Dec 2015 15:57:37 +0000

>>>>> "TZ" == Ted Zlatanov <tzz <at> lifelogs.com> writes:
>>>>> On Tue, 29 Dec 2015 19:25:48 +0000 Ivan Shmakov <ivan <at> siamics.net> wrote:

[…]

 TZ> I think the benefit to the rest of the users will be worth it, and
 TZ> that group can have a ELPA package to support them.

 IS> As long as the hooks are in place to route the requests via that
 IS> package, I have no (strong) objections to the move.

 TZ> The package itself will install those hooks, I assume.

	My point is that there’re no such hooks currently – the dispatch
	is instead hardcoded into network-stream-open-tls:

   357		   (stream
   358		    (funcall (if (gnutls-available-p)
   359				 'open-gnutls-stream
   360			       'open-tls-stream)
   361			     name buffer host service))

	For it to still be possible to use functions other than
	open-gnutls-stream, and assuming open-tls-stream is removed from
	the Emacs proper, this would’ve to be replaced with a
	(customizable) variable, like:

   (stream
    (funcall network-stream-open-tls-function
             name buffer host service))

 IS> But given that tls.el is about 300 LoC in total, and hardly incurs
 IS> a high maintenance cost, I don’t see much value in the move,
 IS> either.

 TZ> There's a small but consistent amount of time spent checking "are
 TZ> you using tls.el?" every time we debug a SSL/TLS issue (even if we
 TZ> don't ask the user explicitly).

 TZ> There is a user experience difference between relying on external
 TZ> tools implicitly, which tls.el does, and explicitly, which
 TZ> ProxyCommand does.

	But that’s trivial to solve; say:

(defcustom network-stream-open-tls-function 'open-gnutls-stream
  "The function to use to establish TLS/SSL connections."
  :type '(choice (function-item :tag "Native GnuTLS support"
                                open-gnutls-stream)
                 (function-item :tag "Use gnutls-cli external command"
                                open-tls-stream)))

	This way, tls.el would only be used if explicitly configured by
	the user.

 TZ> Also, tls.el is not granular like ProxyCommand or the
 TZ> `nnimap-stream' functionality, it applies to all connectivity.

	The user may set network-stream-open-tls-function to an entirely
	arbitrary function, which may take the target host and service
	names into account.  (Although I don’t have any sensible use
	case for that at hand.)

 TZ> I hope that explains my reasoning better.

	It does.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.