GNU bug report logs - #49055
28.0.50; [PATCH] De-obfuscate gnutls_handshake loop

Previous Next

Package: emacs;

Reported by: dick.r.chiang <at> gmail.com

Date: Wed, 16 Jun 2021 01:12:01 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #25 received at 49055 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dick.r.chiang <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 49055 <at> debbugs.gnu.org
Subject: Re: bug#49055: 28.0.50; [PATCH] De-obfuscate gnutls_handshake loop
Date: Sat, 19 Jun 2021 20:51:51 +0300
> From: dick.r.chiang <at> gmail.com
> Cc: 49055 <at> debbugs.gnu.org
> Date: Sat, 19 Jun 2021 13:34:21 -0400
> 
> >   . the gnutls_error_is_fatal call is missing from the new code
> 
> Yes, and just as well since it's redundant with `emacs_gnutls_handle_error`.

Not really, no: emacs_gnutls_handle_error does more, so the code is
not equivalent.

> >   . the negative values of 'ret' (if they are significant) aren't
> >     tested anymore
> 
> This unchanged line 626 begs to differ.
> 
> while ((ret = gnutls_handshake (state)) < 0)

Only if we accept your removal of the inner loop.  Which I don't, at
least not yet; see below.

> >   . the condition of GNUTLS_E_INTERRUPTED is tested only once, and
> >     immediately causes the outer while-loop to be abandoned
> 
> Yes, as the commit before e87e6a2 did.  You do realize I hope that e87e6a2, in
> its desire to keep the loop going under GNUTLS_E_INTERRUPTED, almost
> certainly did not intend to call `gnutls_handshake` twice when
> GNUTLS_E_INTERRUPTED was not applicable.

Oh, yes, it did intend that: the changes are explicitly so that
interrupted calls don't fail because they were interrupted, but are
retried.

> > I'd love to see some rationale for these differences.
> 
> Your skepticism is a credit to your earnestness.  However, your expert
> scrutiny is better applied to misguided commits like e87e6a2 and d84d69d.

The thing is that I understand the changes in e87e6a2, and don't
consider them misguided.  They make Emacs more reliable in the rare
situations where the TLS handshake is interrupted.

What happens with your changes if during the TLS handshake you
repeatedly and quickly press C-g several times?

Paul, I'd appreciate your views on this, please.




This bug report was last modified 4 years and 31 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.