From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22493@debbugs.gnu.org
Subject: bug#22493: 25.1.50; open-gnutls-stream doesn't respect :nowait, so the connections are synchronous
Date: Sat, 30 Jan 2016 23:55:57 +0100 [thread overview]
Message-ID: <87fuxebrsy.fsf@gnus.org> (raw)
In-Reply-To: <83r3gzwhg8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Jan 2016 11:21:43 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> The problem is, though, that the process isn't marked as a gnutls
>> process until gnutls_boot is called, so this needs to happen much
>> earlier. Possibly by adding another keyword to make-network-process
>> that just sets
>>
>> XPROCESS (proc)->gnutls_p = 1;
>
> Why do you need to mark a process gnutls_p, when it definitely still
> isn't, not until the GnuTLS negotiation is successfully completed?
It is a socket that will only be used for TLS. And the current way
we're creating TLS streams is by calling `open-gnutls-stream', which
(simplified) just calls `make-network-stream' and then `gnutls-boot' in
rapid succession. So any stream you get out of `open-gnutls-stream'
will look just the same -- it'll have gnutls_p set.
It'll just happen slightly earlier.
> That'd just add confusion (a.k.a. "bugs waiting to happen") on the C
> level. Can't we use a GnuTLS-specific sentinel instead?
I'm not sure I follow... a sentinel?
>> The other problem is that reading/writing from these things will just
>> send plain text if the gnutls stuff hasn't been initialised:
>>
>> #ifdef HAVE_GNUTLS
>> if (p->gnutls_p && p->gnutls_state)
>> written = emacs_gnutls_write (p, cur_buf, cur_len);
>> else
>> #endif
>> written = emacs_write_sig (outfd, cur_buf, cur_len);
>>
>> I think that looks rather nonsensical.
>
> Does this happen today? If so, in what scenario?
It does not happen today, but it will happen if we open the TLS stream
:nowait. For instance, url.el calls `open-network-stream' and then
sends a "GET /" on the socket immediately. Since setup is synchronous
today, that's fine, but when it gets async, then that p->gnutls_state
will be 0, and url.el will send an unencrypted "GET /" to the server,
which will fail, of course.
> If you want GnuTLS negotiation to happen from the sentinel, you need
> some machinery to block such process objects from communicating.
> I'm not sure silently skipping I/O is TRT for that: won't Lisp
> programs that happen to start communicating too early become confused
> about what's going on?
The "GET /" will block, sort of, as it would on any socket that's backed
up. I don't think there will be anything user-noticeable from, say, the
perspective of `send-process-string'...
> More generally, what advantages do we expect to gain by making these
> changes? Let DNS resolution proceed in the background, only to have
> to wait for GnuTLS negotiations anyway, before we can start using the
> stream? Or are there more significant advantages?
It makes the entire connection, both the DNS resolution and the TLS
negotiation, asynchronous. So Emacs doesn't hang while eww is
connecting to https://google.com.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2016-01-30 22:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-30 4:00 bug#22493: 25.1.50; open-gnutls-stream doesn't respect :nowait, so the connections are synchronous Lars Ingebrigtsen
2016-01-30 4:45 ` Lars Ingebrigtsen
2016-01-30 9:21 ` Eli Zaretskii
2016-01-30 22:55 ` Lars Ingebrigtsen [this message]
2016-01-31 0:40 ` Lars Ingebrigtsen
2016-01-31 1:10 ` Lars Ingebrigtsen
2016-01-31 16:00 ` Eli Zaretskii
2016-01-31 15:59 ` Eli Zaretskii
2016-01-31 23:17 ` Lars Ingebrigtsen
2016-02-01 2:41 ` Lars Ingebrigtsen
2016-02-01 3:41 ` Eli Zaretskii
2016-02-01 4:01 ` Lars Ingebrigtsen
2016-02-01 18:50 ` Eli Zaretskii
2016-02-02 1:43 ` Lars Ingebrigtsen
2016-02-02 16:10 ` Eli Zaretskii
2016-02-03 1:10 ` Lars Ingebrigtsen
2016-02-03 1:58 ` Lars Ingebrigtsen
2016-02-03 15:52 ` Eli Zaretskii
2016-02-04 2:47 ` Lars Ingebrigtsen
2016-02-04 16:39 ` Eli Zaretskii
2016-02-05 2:36 ` Lars Ingebrigtsen
2016-02-05 7:24 ` Eli Zaretskii
2016-02-05 7:34 ` Lars Ingebrigtsen
2016-02-05 9:18 ` Eli Zaretskii
2016-02-06 3:03 ` Lars Ingebrigtsen
2016-02-06 7:51 ` Eli Zaretskii
2016-02-06 7:57 ` Lars Ingebrigtsen
2016-02-03 15:51 ` Eli Zaretskii
2016-02-04 2:59 ` Lars Ingebrigtsen
2016-01-31 15:57 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fuxebrsy.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=22493@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).