[gnutls-devel] GnuTLS | Bugs and wrong documentation for gnutls_x509_trust_list_add_cas, gnutls_x509_trust_list_add_crls and gnutls_x509_trust_list_add_trust_mem (#552)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Wed Aug 29 18:55:50 CEST 2018

New Issue was created.

Issue 552: https://gitlab.com/gnutls/gnutls/issues/552
Author:    Tim Kosse

# 1) The documentation for gnutls_x509_trust_list_add_cas is not correct:

> If the flag GNUTLS_TL_NO_DUPLICATES is specified, then
> the provided clist entries that are duplicates will not be
> added to the list and will be deinitialized.
> Returns: The number of added elements is returned.

The actual behavior is that the existing entries in the list will be deinitialized and replaced with the entries from clist.

The return value includes both added _and_ replaced entries.

The documentation does not mention that this behavior also applies to GNUTLS_TL_NO_DUPLICATE_KEY.

> The list of CAs must not be deinitialized during this structure's lifetime.

I find this misleading, I suggest rewording it to "The CAs in clist must not be deinitialized during the lifetime of list."

Also this needs to be added: "If either the flags GNUTLS_TL_NO_DUPLICATES or GNUTLS_TL_NO_DUPLICATE_KEY are given, it required gnutls_x509_trust_list_deinit will be called with all=1.

# 2) The documentation for gnutls_x509_trust_list_add_crls is not correct:

Similarly to add_cas, gnutls_x509_trust_list_add_crls can replace existing crls and returns the sum of added and replaced entries when the GNUTLS_TL_NO_DUPLICATES flag is passed, though it depends which crl is newer.

Likewise, the lifetime remark is misleading here as well.

# 3) Wrong return value in gnutls_x509_trust_list_add_cas:

If the GNUTLS_TL_USE_IN_TLS flag is given and add_new_ca_to_rdn_seq fails, the CA already got added to the list, but the return value does not include it.

# 4) Memory leak in gnutls_x509_trust_list_add_trust_mem:

If gnutls_x509_trust_list_add_cas returns less than clist_size, the extra certificates not added will never be freed. Compare with gnutls_x509_trust_list_add_crls which does not have this problem.

Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/552
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20180829/6e660601/attachment.html>

More information about the Gnutls-devel mailing list