bug#34341: 26.1; url-retrieve-synchronously returns blank buffer

[Robert Pluim]

>>>>> On Sat, 04 May 2019 11:18:30 -0400, Noam Postavsky <npostavs@gmail.com> 
>>>>> said:

    Noam> Laurent Charignon <l.charignon@gmail.com> writes:
    >> #### Context
    >> 
    >> The symptom of this issue first came up in the context of
    >> `ghub`, a package that offers interfacing with Github from
    >> emacs (issue: https://github.com/magit/ghub/issues/81).
    >> 
    >> Multiple users of the `ghub` package started observing that
    >> synchronously retrieving content from the github API through
    >> ghub returned blank responses.

    >> (switch-to-buffer (url-retrieve-synchronously "
    >> https://api.github.com/users/charignon/repos";) (buffer-string))

    >> From bisecting, I know that the fix is in between 191a5568db
    >> (working) and 2a3bd6798e96708 (not working). It is hard to
    >> pinpoint further due to segfaults that were introduced then
    >> fixed in this range. My best guess is that "Fix unlikely races
    >> with GnuTLS, datagrams" (e87e6a24c4) resolved this.

    Noam> I can confirm that cherrypicking this commit fixes the
    Noam> problem on my Arch box which has gnutls 3.6.7 (doesn't occur
    Noam> at all on my Debian box with gnutls 3.5.8).

    Noam> Since the only recourse for users hitting is rebuilding
    Noam> --without-gnutls or (advice-add 'gnutls-available-p
    Noam> :override #'ignore) which falls back to the obsolete tls.el,
    Noam> I'd say this is important enough to backport to emacs-26.
    Noam> I'll do that in a couple of days if there are no objections.

Are you sure thatʼs the only recourse? When I hit this issue, turning
off TLS1.3 support helped as well. (see
<https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00393.html>
and
<https://lists.gnu.org/archive/html/help-gnu-emacs/2019-02/msg00196.html>)

Something like:

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

would be one way to turn off TLS1.3

Robert