[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19284: 25.0.50; tls.el uses option --insecure
From: |
Ivan Shmakov |
Subject: |
bug#19284: 25.0.50; tls.el uses option --insecure |
Date: |
Wed, 30 Dec 2015 15:57:37 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Tue, 29 Dec 2015 19:25:48 +0000 Ivan Shmakov <ivan@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