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

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 30 Dec 2015 15:57:37 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

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

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.

IS> 	My point is that there’re no such hooks currently

You're right, I meant to say that the hooks will be provided and the
package will add itself to them.

IS> 	– the dispatch is instead hardcoded into
IS> 	network-stream-open-tls:

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

Yes, this is exactly where the hook or function should go.

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

IS> 	But that’s trivial to solve; say:

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

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

Exactly, brilliant :)

But the user experience goes beyond configuration. External tools are
harder to debug and control, and the *user* ends up with the burden of
maintaining them (which can have security consequences too). I think if
the user *knows* he has chosen a proxy method, he's much more likely to
be aware of the burden he assumes.

It's also worth considering whether the GnuTLS integration itself can
support these use cases. Maybe `open-gnutls-stream-insecurely' would be
a good user-level function to provide.

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

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

It makes sense in some very specifically constrained corporate
environments. It could be handled by making
`network-stream-open-tls-function' optionally specify the function by
host and port, not just a global choice. Gnus is full of this kind of
defcustom.

So that makes it fairly easy to configure, I think. The logging in the
network-stream code will probably have to be improved as well to support
the user experience.

I appreciate your thoughts, Ivan, but also anyone else that wants to
contribute is welcome... I think this is a very good discussion.

Ted