Re: libcrypto: wrapper for internal x509v3_cache_extensions()

2023-01-20 Thread Theo Buehler
On Fri, Jan 20, 2023 at 09:13:04PM +, Job Snijders wrote: > On Fri, Jan 20, 2023 at 09:35:08PM +0100, Theo Buehler wrote: > > On Fri, Jan 20, 2023 at 08:06:00PM +, Job Snijders wrote: > > > While studying why X509_check_ca() is the ugly thing it is, tb@ > > > suggested x509v3_cache_extensio

Re: libcrypto: wrapper for internal x509v3_cache_extensions()

2023-01-20 Thread Job Snijders
On Fri, Jan 20, 2023 at 09:35:08PM +0100, Theo Buehler wrote: > On Fri, Jan 20, 2023 at 08:06:00PM +, Job Snijders wrote: > > While studying why X509_check_ca() is the ugly thing it is, tb@ > > suggested x509v3_cache_extensions() might benefit from a wrapper to > > avoid duplication of locking

Re: libcrypto: wrapper for internal x509v3_cache_extensions()

2023-01-20 Thread Theo Buehler
On Fri, Jan 20, 2023 at 08:06:00PM +, Job Snijders wrote: > While studying why X509_check_ca() is the ugly thing it is, tb@ > suggested x509v3_cache_extensions() might benefit from a wrapper to > avoid duplication of locking and checking the stupid EXFLAG_INVALID > flag. x509v3_cache_extensions

libcrypto: wrapper for internal x509v3_cache_extensions()

2023-01-20 Thread Job Snijders
While studying why X509_check_ca() is the ugly thing it is, tb@ suggested x509v3_cache_extensions() might benefit from a wrapper to avoid duplication of locking and checking the stupid EXFLAG_INVALID flag. x509v3_cache_extensions() isn't a public function anyway. Passes regress & rpki-client. OK?