bug#19284: 25.0.50; tls.el uses option --insecure

[Ivan Shmakov]

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