6 a.m.
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
---------------------------------------------------------------
commit 9eb72b454b83441329e9c84eb88041140d201ea3
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Thu Nov 13 12:24:37 2014 +0100
GNUTLS: Document that the pitfalls have been addressed
Suggested by Nikos Mavrogiannopoulos.
---------------------------------------------------------------
defensive-coding/en-US/Features-TLS.xml | 85 ++++++++++++++++++------------
1 files changed, 51 insertions(+), 34 deletions(-)
diff --git a/defensive-coding/en-US/Features-TLS.xml
b/defensive-coding/en-US/Features-TLS.xml
index 5d9e39d..a2c0afd 100644
--- a/defensive-coding/en-US/Features-TLS.xml
+++ b/defensive-coding/en-US/Features-TLS.xml
@@ -215,41 +215,58 @@
<section id="sect-Defensive_Coding-TLS-Pitfalls-GNUTLS">
<title>GNUTLS Pitfalls</title>
<para>
- <filename>libgnutls.so.26</filename> links to
- <filename>libpthread.so.0</filename>. Loading the threading
- library too late causes problems, so the main program should
- be linked with <literal>-lpthread</literal> as well. As a
- result, it can be difficult to use GNUTLS in a plugin which is
- loaded with the <function>dlopen</function> function. Another
- 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.
- </para>
- <para>
- The <function>gnutls_global_init</function> function must be
- called before using any functionality provided by the library.
- This function is not thread-safe, so external locking is
- required, but it is not clear which lock should be used.
- 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.
- </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.
- </para>
- <para>
- The X.509 implementation in GNUTLS is rather lenient. For
- example, it is possible to create and process X.509
- version 1 certificates which carry extensions. These
- certificates are (correctly) rejected by other
- implementations.
+ Older versions of GNUTLS had several peculiarities. As of
+ GNUTLS 3.3.10, they have been addressed, so these are only a
+ concern for applications which have to run with older GNUTLS
+ versions.
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The dynamic shared object provided by GNTULS links to
+ <filename>libpthread.so.0</filename>. Loading the
+ threading library too late causes problems, so the main
+ program should be linked with <literal>-lpthread</literal>
+ as well. As a result, it can be difficult to use GNUTLS
+ in a plugin which is loaded with the
+ <function>dlopen</function> function. Another 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <function>gnutls_global_init</function> function must
+ be called before using any functionality provided by the
+ library. This function is not thread-safe, so external
+ locking is required, but it is not clear which lock should
+ be used. 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.
+ </para>
+ </listitem>
+ <listitem>
+ <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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The X.509 implementation in GNUTLS is rather lenient. For
+ example, it is possible to create and process X.509
+ version 1 certificates which carry extensions. These
+ certificates are (correctly) rejected by other
+ implementations.
+ </para>
+ </listitem>
+ </itemizedlist>
</section>
<section id="sect-Defensive_Coding-TLS-Pitfalls-OpenJDK">
<title>OpenJDK Pitfalls</title>