From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs 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 Message-ID: <87fuxebrsy.fsf@gnus.org> References: <87mvrnzpge.fsf@gnus.org> <878u37zndq.fsf@gnus.org> <83r3gzwhg8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454194649 22816 80.91.229.3 (30 Jan 2016 22:57:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2016 22:57:29 +0000 (UTC) Cc: 22493@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 30 23:57:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aPeS7-0006bI-Gb for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 23:57:11 +0100 Original-Received: from localhost ([::1]:39987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPeS7-0006ob-2E for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 17:57:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPeS2-0006nq-Qg for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 17:57:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPeRy-0002BR-PY for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 17:57:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPeRy-0002BK-Lr for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 17:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPeRy-0000Sx-Bn for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 17:57:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jan 2016 22:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22493 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22493-submit@debbugs.gnu.org id=B22493.14541945901750 (code B ref 22493); Sat, 30 Jan 2016 22:57:02 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 30 Jan 2016 22:56:30 +0000 Original-Received: from localhost ([127.0.0.1]:42384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPeRS-0000SA-KN for submit@debbugs.gnu.org; Sat, 30 Jan 2016 17:56:30 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:45674) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPeRQ-0000S2-Tf for 22493@debbugs.gnu.org; Sat, 30 Jan 2016 17:56:29 -0500 Original-Received: from cpe-60-225-211-161.nsw.bigpond.net.au ([60.225.211.161] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aPeR0-0002uH-Eo; Sat, 30 Jan 2016 23:56:03 +0100 In-Reply-To: <83r3gzwhg8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Jan 2016 11:21:43 +0200") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) X-MailScanner-ID: 1aPeR0-0002uH-Eo MailScanner-NULL-Check: 1454799365.98664@L1+7+JK3JtY1SB8AC/Qa6w X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112114 Archived-At: Eli Zaretskii 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