Re: [Nbd] [PATCH] build: Fix build with older gcc

[Wouter Verhelst <w@...112...>]

On Tue, Dec 20, 2016 at 09:01:09AM -0600, Eric Blake wrote:
> On 12/20/2016 08:12 AM, Wouter Verhelst wrote:
> 
> >>> Can you verify if the problem persists with today's git HEAD?
> >>
> >> The compilation failure due to redefinition of typedefs is still present
> >> in the 3.15.1 release.
> > 
> > Yes, I forgot about that part, sorry.
> > 
> >> The testsuite failures of ./tls and ./tlshuge are likewise still
> >> present, so it's definitely something related to the older gnutls version.
> > 
> > Okay, I'll see if I can fire up a RHEL6 VM then, and see if I can
> > reproduce/fix it.
> 
> A CentOS VM is probably equally effective for catching the problem, and
> without the cost of a Red Hat subscription.

... and is what I meant ;-)

It turns out that GnuTLS on CentOS 6 is at 2.8, which is not quite
recent enough. On EPEL, I find GnuTLS 3.5, which would not reproduce the
problem.

Compiling GnuTLS 2.12 from source was an adventure (I remember now why
I don't use source distributions), but it turns out it segfaults for me
(on every call, not just the TLS-using ones) when the server generates
DH parameters, because it tries to do a pthread_mutex_lock().

The reason for that is that we're not calling gnutls_global_init(). This
is optional since GnuTLS 3.3 (where this function is called implicitly),
but required for older versions. I'm not sure why you didn't run against
that, but I'll fix that in a separate commit.

Having said that, the problem you're running up against occurs when we
parse the priority string.  This is because we set %SERVER_PRECEDENCE,
which GnuTLS 2.12 doesn't support yet. Luckily, this is only a hint for
GnuTLS that it should prefer the priority string as passed to GnuTLS,
rather than accept whatever the client sends, so we should be able to
remove it on those versions where it is not (yet) supported. However,
unfortunately the documentation doesn't list at which version of GnuTLS
support for %SERVER_PRECEDENCE was added.

I think the easiest way to fix this is to add a global configuration
parameter "tlsprio" or some such to set the priority string manually.
This can then default to the string we're using right now, but you can
modify it manually if needs be. It's probably a good idea to allow the
configuration of such priority strings anyway. I'll look at that later. 

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12