Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 9eb72b454b83441329e9c84eb88041140d201ea3 Author: Florian Weimer <fweimer@xxxxxxxxxx> 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> -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
