>From ba5b7ea69e323436d3947755b67f7b61e124af9c Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx>
Date: Mon, 13 Oct 2014 14:05:31 +0200
Subject: [PATCH] updated gnutls pitfalls
---
defensive-coding/en-US/Features-TLS.xml | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml
index 5d9e39d..46c6e42 100644
--- a/defensive-coding/en-US/Features-TLS.xml
+++ b/defensive-coding/en-US/Features-TLS.xml
@@ -224,7 +224,9 @@
side effect is that applications which merely link against
GNUTLS (even without actually using it) may incur a
substantial overhead because other libraries automatically
- switch to thread-safe algorithms.
+ switch to thread-safe algorithms. This does not apply to
+ libgnutls.so.28 shipped in Fedora 21, which does not link to
+ libpthread.
</para>
<para>
The <function>gnutls_global_init</function> function must be
@@ -234,14 +236,18 @@
Omitting the synchronization does not just lead to a memory
leak, as it is suggested in the GNUTLS documentation, but to
undefined behavior because there is no barrier that would
- enforce memory ordering.
+ enforce memory ordering. This no longer applies to GnuTLS
+ 3.3.x shipped in Fedora 21, as the global initialization function
+ was moved to an ELF constructor.
</para>
<para>
The <function>gnutls_global_deinit</function> function does
not actually deallocate all resources allocated by
<function>gnutls_global_init</function>. It is currently not
thread-safe. Therefore, it is best to avoid calling it
- altogether.
+ altogether. This no longer applies to GnuTLS
+ 3.3.x shipped in Fedora 21, as the global initialization function
+ was moved to an ELF destructor.
</para>
<para>
The X.509 implementation in GNUTLS is rather lenient. For
--
1.9.3
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
