From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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 11:21:43 +0200 Message-ID: <83r3gzwhg8.fsf@gnu.org> References: <87mvrnzpge.fsf@gnus.org> <878u37zndq.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454145809 11970 80.91.229.3 (30 Jan 2016 09:23:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2016 09:23:29 +0000 (UTC) Cc: 22493@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 30 10:23:18 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 1aPRkS-0004y8-6I for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 10:23:16 +0100 Original-Received: from localhost ([::1]:38006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPRkR-00087d-AO for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 04:23:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPRkJ-00087U-NV for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 04:23:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPRkE-00056s-JN for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 04:23:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPRkE-00056o-FU for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 04:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPRkE-0008N5-AX for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 04:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jan 2016 09:23: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.145414575232129 (code B ref 22493); Sat, 30 Jan 2016 09:23:02 +0000 Original-Received: (at 22493) by debbugs.gnu.org; 30 Jan 2016 09:22:32 +0000 Original-Received: from localhost ([127.0.0.1]:41006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPRjg-0008M6-TV for submit@debbugs.gnu.org; Sat, 30 Jan 2016 04:22:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46717) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPRjc-0008Lq-1O for 22493@debbugs.gnu.org; Sat, 30 Jan 2016 04:22:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPRjS-000502-3e for 22493@debbugs.gnu.org; Sat, 30 Jan 2016 04:22:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPRjS-0004zy-09; Sat, 30 Jan 2016 04:22:14 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1491 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aPRjR-0001C7-DR; Sat, 30 Jan 2016 04:22:13 -0500 In-reply-to: <878u37zndq.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Jan 2016 05:45:21 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:112101 Archived-At: > From: Lars Ingebrigtsen > Date: Sat, 30 Jan 2016 05:45:21 +0100 > > First of all, gnutls-open-stream should call open-network-stream with > :nowait, and put a sentinel on the stream to see when it's opened, and > then it should call gnutls-negotiate from the sentinel. > > 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? 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? > 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? > If it's p->gnutls_p, then it should never write to the process, no > matter what the state is. Rather is should just skip writing until > p->gnutls_state gets set (which happens during gnutls_boot). > > Or is there something subtle here I'm missing? When would we ever want > to write plain text to something that's p->gnutls_p? 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? 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? Thanks.