From: Ted Zlatanov <tzz@lifelogs.com>
To: Ivan Shmakov <ivan@siamics.net>
Cc: 19284@debbugs.gnu.org
Subject: bug#19284: 25.0.50; tls.el uses option --insecure
Date: Wed, 30 Dec 2015 11:38:13 -0500 [thread overview]
Message-ID: <87lh8bzybu.fsf@lifelogs.com> (raw)
In-Reply-To: <87lh8cvsi6.fsf@violet.siamics.net> (Ivan Shmakov's message of "Wed, 30 Dec 2015 15:57:37 +0000")
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
next prev parent reply other threads:[~2015-12-30 16:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 19:43 bug#19284: 25.0.50; tls.el uses option --insecure Jens Lechtenboerger
2015-12-26 21:15 ` Lars Ingebrigtsen
2015-12-26 21:39 ` Andreas Schwab
2015-12-26 21:49 ` Lars Ingebrigtsen
2015-12-27 9:59 ` Andreas Schwab
2015-12-28 22:04 ` Ted Zlatanov
2015-12-29 13:29 ` Lars Ingebrigtsen
2015-12-29 19:25 ` Ivan Shmakov
2015-12-30 14:46 ` Ted Zlatanov
2015-12-30 15:57 ` Ivan Shmakov
2015-12-30 16:38 ` Ted Zlatanov [this message]
2015-12-30 18:22 ` Lars Magne Ingebrigtsen
2015-12-31 16:00 ` Ted Zlatanov
2015-12-31 18:32 ` Ivan Shmakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lh8bzybu.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=19284@debbugs.gnu.org \
--cc=ivan@siamics.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.