Bugzilla – Bug 6038
Upgrade GnuTLS to latest version
Last modified: 2017-03-24 10:54:34
You need to
before you can comment on or make changes to this bug.
using 3.5.1, latest is 3.5.4. As far as I can tell from
http://www.gnutls.org/security.html, there are no critical bugs affecting us.
Updating to 3.5.6 which are a bugfix release just like 3.5.5.
tlwebaccess and tlwebadm work fine with both Firefox and Chrome. The generated
GnuTLS appendix in the TAG also look fine.
> The connection to this site is encrypted and authenticated using
> a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA),
> and a strong cipher (AES_128_GCM).
I can't connect to tlwebadm/tlwebaccess in nightly builds.
tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal,
Description: Unexpected Message)" to a ClientHello msg.
Browsers report this as:
> This site can’t be reached
> localhost unexpectedly closed the connection.
Urgh. This was a fun one.
This is caused by a lovely quirk in libc. It has stubs for most pthread
functions that just return success. If the real libpthread is pulled in then
those stubs are replaced by the real thing.
This can easily go south if this happens after a while, rather than when the
process is started. A mutex you initialised with the stub routines is a poor
fit for the real pthread_mutex_lock().
And this is precisely what happened here. pthread_mutex_lock() returned an
error on the bogus mutex, and GnuTLS called abort() when it couldn't grab the
The fix is to always link to libpthread when using pthread functions. Upstream
has also gotten this wrong, so I filed a bug there:
This issue is old and should theoretically be happening on most versions of
ThinLinc. However we seem to be getting lucky and getting zeroed out memory
from malloc() when initialising these early mutexes. And as it happens, glibc's
implementation of pthread_mutex_init() also results in a zeroed out structure.
So these mutexes work despite only the stubs being loaded.
The new version of GnuTLS is causing some reordering of calls, and we're not
getting clean memory from malloc() anymore. Hence things are now crashing
Should be all done now.
The new tests found three components for which we didn't properly link to
libpthread; tlstunnel, mesa, and opensc. Whereof tlstunnel was the only one
where we observed an actual problem (comment #4), however all these three
components have been fixed now.
The tests pass and I have verified that tlwebaccess and tlwebadm works with
The tests for linkage of pthread added in commit r31918, does no run with
success at nightly build.
(In reply to comment #4)
> I can't connect to tlwebadm/tlwebaccess in nightly builds.
> tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal,
> Description: Unexpected Message)" to a ClientHello msg.
> Browsers report this as:
> > This site can’t be reached
> > localhost unexpectedly closed the connection.
> > ERR_CONNECTION_CLOSED
Verified that tlwebadm and tlwebacces works as expected using ThinLinc build
The new test for correct linkage and the fixes for few comoponents looks good.