bug#25061: consider adding %COMPAT to default gnutls priority string

[Andy Wingo <wingo@igalia.com>]

On Mon 30 Jan 2017 09:01, ludo@gnu.org (Ludovic Courtès) writes:

> Lars Ingebrigtsen <larsi@gnus.org> skribis:
>
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>
>>> On Thu, 01 Dec 2016 21:25:29 +0100 ludo@gnu.org (Ludovic Courtès) wrote: 
>>>
>>> LC> Ted Zlatanov <tzz@lifelogs.com> skribis:
>>>
>>>>> We could break down %COMPAT to all its components and find which ones
>>>>> are causing the issue.
>>>
>>> LC> %DUMBFW may be that option (info "(gnutls) Priority Strings"):
>>>
>>> LC> will add a private extension with bogus data that make the
>>> LC> client hello exceed 512 bytes. This avoids a black hole
>>> LC> behavior in some firewalls. This is the [_rfc7685_] client
>>> LC> hello padding extension, also enabled with %COMPAT.
>>>
>>> Nice. Could you or Andy verify if it resolves the originally reported
>>> problem? I think it's very reasonable to add it to the default, if it does.
>>
>> Yes, I think so, too.  Did anyone of you check whether it fixed the problems?
>
> I’m just a passerby so I haven’t tested.  ;-)
>
> I think Andy has been traveling lately but he might be able to check
> later.

I tried checking (had to remember what I was doing to begin with!) and
was not able to reproduce the original problem, and therefore couldn't
test NORMAL:%COMPAT or NORMAL:%DUMBFW :/  Sorry :/

I was trying to just do this:

  ;; uncomment to test original proposed workaround
  ;; (setq gnutls-algorithm-priority "NORMAL:%COMPAT")
  (setq gnutls-log-level 2)
  (url-retrieve "https://mirror.hydra.gnu.org/"
                #'(lambda (status)
                    (message "success")))

and evaluating that last form a number of times.  Not very scientific :P
I was unable to reproduce the problem though.

Andy