[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25061: consider adding %COMPAT to default gnutls priority string
From: |
Ludovic Courtès |
Subject: |
bug#25061: consider adding %COMPAT to default gnutls priority string |
Date: |
Thu, 01 Dec 2016 21:25:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Ted Zlatanov <tzz@lifelogs.com> skribis:
> On Tue, 29 Nov 2016 11:24:53 +0100 Andy Wingo <wingo@igalia.com> wrote:
>
> AW> There have been reports of errors from people using melpa and so on
> AW> which manifest themselves as:
>
> AW> gnutls.c: [0] (Emacs) fatal error: The TLS connection was
> non-properly terminated.
> ...
> AW> So, as Ludovic suggests in his message, a workaround might be:
>
> AW> (setq gnutls-algorithm-priority "NORMAL:%COMPAT")
>
> AW> See Ludovic's message for some justification. Just an idea. I have
> AW> been trying to reproduce the problem that people report locally as some
> AW> TLS errors but I have not been able to.
>
> We could break down %COMPAT to all its components and find which ones
> are causing the issue.
%DUMBFW may be that option (info "(gnutls) Priority Strings"):
--8<---------------cut here---------------start------------->8---
%DUMBFW will add a private extension
with bogus data that make the
client hello exceed 512 bytes.
This avoids a black hole
behavior in some firewalls.
This is the [_rfc7685_] client
hello padding extension, also
enabled with %COMPAT.
--8<---------------cut here---------------end--------------->8---
(Somehow I don’t recall seeing it back in the day.)
Ludo’.