[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19284: 25.0.50; tls.el uses option --insecure
From: |
Ted Zlatanov |
Subject: |
bug#19284: 25.0.50; tls.el uses option --insecure |
Date: |
Wed, 30 Dec 2015 11:38:13 -0500 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
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