From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#40665: 28.0.50; tls hang on local ssl Date: Sun, 19 Apr 2020 16:34:38 +0200 Message-ID: References: <86wo6fo78r.fsf@mail.3qin.us> <86imhz5m0f.fsf@mail.3qin.us> <86h7xj5fae.fsf@mail.3qin.us> <86ftd35930.fsf@mail.3qin.us> <86d086dkgq.fsf@mail.3qin.us> <86eeslecnf.fsf@mail.3qin.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="8156"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40665@debbugs.gnu.org To: Derek Zhou Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 19 16:35:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQB2T-00020I-DU for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 16:35:17 +0200 Original-Received: from localhost ([::1]:42448 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQB2S-00026t-Fj for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Apr 2020 10:35:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47328) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQB2E-0001y2-OG for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 10:35:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQB2E-0004fs-5w for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 10:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQB2D-0004fJ-Oq for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 10:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQB2D-0003qu-MR for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2020 10:35:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <86wo6fo78r.fsf@mail.3qin.us> Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2020 14:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40665 X-GNU-PR-Package: emacs Original-Received: via spool by 40665-submit@debbugs.gnu.org id=B40665.158730688814785 (code B ref 40665); Sun, 19 Apr 2020 14:35:01 +0000 Original-Received: (at 40665) by debbugs.gnu.org; 19 Apr 2020 14:34:48 +0000 Original-Received: from localhost ([127.0.0.1]:45678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQB1z-0003qO-Mj for submit@debbugs.gnu.org; Sun, 19 Apr 2020 10:34:47 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:42716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQB1y-0003qA-EX for 40665@debbugs.gnu.org; Sun, 19 Apr 2020 10:34:46 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id j2so8769211wrs.9 for <40665@debbugs.gnu.org>; Sun, 19 Apr 2020 07:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:message-id:references:date:mime-version :content-transfer-encoding; bh=sJjmis/yT/OpPEXYZdJqET5vUGIpPdBjKO1QWOdc22U=; b=kg+gs63pOZmTTYMlmiUluWhIMqOhbQebVyrniRJ9Y1Lje9gtQ4HNDTroxXGexh7two ULuwdYV9PxWbUu8IdH5uGHpeqReTsvxEbrtEii6JjgXXBWNImXeFyDQ5ad905fGrRp2+ ML/RAyNrOg3MJ4AQ51dhCy05k22v7fUs2kts+eqNYoTtZ3BA8hxo05Y8XHctVNjggIc/ OPQWeI9OSNE5M1P2zAfnAACo9986dpFoqCRuSXksQt5jFxtSCD0qnn77XDJ8Rz/NWYSC Kh3Lbi9xRA41A4biCg1pQMv78mChKx2JhgG6xPvq2JhrG0cJfXGAWC+J1BGLqvVPG2p4 qHUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:references:date :mime-version:content-transfer-encoding; bh=sJjmis/yT/OpPEXYZdJqET5vUGIpPdBjKO1QWOdc22U=; b=TxQciLkOgt2jWIR93jgoHi1jVFjWjLmnB2yGDxh82+jxjW5eFRSyZmuvDrjdxOD0Qt z5xSscrgkUgakVcvS1WHRRMBWG53h3Xo6TmqOFFjh5EDkZCftox0OQJAXv2aC2M5dCjw VWvXqjmRYHk5KQMa6Rd428URJfLqVPP+s9UoDnRnsrku3lkdzU+Bz/70MR+Pgb2BDlF+ py5dqU0FB04tQCrBMphWcyGra0Fd0VHAaReSB1aMMYBrxBSNRd9KYLOvkN5mw7BeeNHH 1eNpbf55HKUSrVBwsP63ngLwk6jP65P6PYK8HzhBiPWu/nDu3BWdQWlDb0QBh9TyjbEK MbWA== X-Gm-Message-State: AGi0PuZ9uOLIW67QuXTCbom0PXYibfNgHXsBkMRyliniftbIxK28gFBB KJ1PtHlStPtjlQR54Tpb7BS4CMzR X-Google-Smtp-Source: APiQypKTdPxXwbkc3ploxMCOjKSPUEsTvdIRZOc18srCEGplrgNlbdIT7tqYA5SzYZdh/Fz5eRjghw== X-Received: by 2002:adf:a15d:: with SMTP id r29mr13113173wrr.134.1587306880031; Sun, 19 Apr 2020 07:34:40 -0700 (PDT) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:4dd7:4da5:1258:da60]) by smtp.gmail.com with ESMTPSA id x18sm10498927wrv.12.2020.04.19.07.34.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2020 07:34:39 -0700 (PDT) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178640 Archived-At: >>>>> On Sat, 18 Apr 2020 02:44:05 +0000 (UTC), Derek Zhou = said: Derek> Derek Zhou writes: >> When this thing happens, the tls handshakes are done properly. Howev= er, >> emacs did not write anything into gnutls before starting to read and >> obviously cannot get anything out at all. It is not really a hang, b= ut >> write never happen and the display buffer stays empty. >>=20 >> Derek Derek> Took my nearly the whole day to debug, but this one-line patch f= ixed my Derek> problem. Derek> My server finishes tls handshake within the gnutls_boot itself, = and if the Derek> sentinel is not called right after, it will never be called so w= rite Derek> will not happen. Someone should review this carefully. Derek> diff --git a/src/process.c b/src/process.c Derek> index 91d426103d..6d497ef854 100644 Derek> --- a/src/process.c Derek> +++ b/src/process.c Derek> @@ -5937,8 +5937,7 @@ wait_reading_process_output (intmax_t time= _limit, int nsecs, int read_kbd, Derek> /* If we have an incompletely set up TLS connection, Derek> then defer the sentinel signaling until Derek> later. */ Derek> - if (NILP (p->gnutls_boot_parameters) Derek> - && !p->gnutls_p) Derek> + if (NILP (p->gnutls_boot_parameters)) Derek> #endif Derek> { Derek> pset_status (p, Qrun); Here=CA=BCs what I think is happening: The only way for p->gnutls_boot_parameters to become nil is here in connect_network_socket: if (p->gnutls_initstage =3D=3D GNUTLS_STAGE_READY) { p->gnutls_boot_parameters =3D Qnil; /* Run sentinels, etc. */ finish_after_tls_connection (proc); } and finish_after_tls_connection should call the sentinel, but NON_BLOCKING_CONNECT_FD is still set, so it doesn=CA=BCt. The next chance to call the sentinel would be from wait_reading_process_output, but only if handshaking has been tried and not completed, except it is complete already. wait_reading_process_output then calls delete_write_fd, which clears NON_BLOCKING_CONNECT_FD, and doesn=CA=BCt run the sentinel because p->gnutls_boot_parameters is nil and p->gnutls_p is true finish_after_tls_connection never gets another chance to run, since the socket is connected and handshaking is complete. After your change, you've fixed this case: if p->gnutls_boot_parameters is nil, that means the handshake completed already and the TLS connection is up, so calling the sentinel is ok. In other cases where the handshake does not complete straight away in Fgnutls_boot, it will complete here in wait_reading_process_output /* Continue TLS negotiation. */ if (p->gnutls_initstage =3D=3D GNUTLS_STAGE_HANDSHAKE_TRIED && p->is_non_blocking_client) { gnutls_try_handshake (p); p->gnutls_handshakes_tried++; if (p->gnutls_initstage =3D=3D GNUTLS_STAGE_READY) { gnutls_verify_boot (aproc, Qnil); finish_after_tls_connection (aproc); } which always happens after delete_write_fd has been called, which clears NON_BLOCKING_CONNECT_FD, so finish_after_tls_connection calls the sentinel. One change we could make is to set p->gnutls_boot_parameters to nil here, so that in the sequence Fgnutls_boot, handshake does not complete handshake succeeds first time in wait_reading_process_output delete_write_fd then checks p->gnutls_boot_parameters the sentinel ends up getting run, but I=CA=BCve not seen the handshake ever succeed straight away before the delete_write_fd, and if it ever has in the wild we would have seen bug reports (and this is dragon-filled code, so I don=CA=BCt want to make changes to it if I can help it :-)) In short: I think the change is ok. It passes the network-stream tests, so I=CA=BCll run with it for a while, and push it in a week or so. Robert