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
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 is 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.