[gnutls-devel] GnuTLS | lib/system/certs.c: Add support for SSL_CERT_DIR, SSL_CERT_FILE (!1541)

[Read-only notification of GnuTLS library development activities]

Ryan Sundberg commented on a discussion on lib/system/certs.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1541#note_852837122

>  #endif
>  
>  #if defined(ENABLE_PKCS11) && defined(DEFAULT_TRUST_STORE_PKCS11)
> -	ret =
> -	    gnutls_x509_trust_list_add_trust_file(list,
> -						  DEFAULT_TRUST_STORE_PKCS11,
> -						  crl_file,
> -						  GNUTLS_X509_FMT_DER,
> -						  tl_flags, tl_vflags);
> -	if (ret > 0)
> -		r += ret;
> +	if (r == 0) {

I was trying to be security conscious while merging the two functions together. My thought here was that if the user has some method explicitly configured for the root certs, it should short circuit on the first one and return there.  For example, if the user has a PKCS11 module for the root certs, and some certs are loaded from there, the environment variable should not be read (it should ONLY use the pkcs11 certs). Or if they have the environment variable set, and some are loaded, it should bypass loading the default /etc/ssl/certs.

I don't know how many installations are out there with both `DEFAULT_TRUST_STORE_PKCS11` and `DEFAULT_TRUST_STORE_FILE` configured, if any, where this may affect them if they wanted to load certs from more than one default source concurrently.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1541#note_852837122
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/20220223/ab7783df/attachment-0001.html>