I think I spot an alternate option.

It looks like SSL_set1_verify_cert_store overrides in the SSL object the X509_STORE provided by the global SSL_CTX object. Further, OpenSSL does an atomic refcount on the X509_STORE copies.

So, one scheme could be:

1. Have a global X509_STORE *current_x509_store object. Each time a new SSL object is made, grab a read lock, invoke SSL_set1_verify_cert_store(ssl, current_x509_store), and then release the read lock.
2. Have a 'refresh' thread that, once an hour, creates a new X509_STORE *new_x509_store = X509_STORE_new(), grabs a write lock, calls X509_STORE_free(current_x509_store), does current_x509_store = new_x509_store, then release the write lock.

The refcounts are then handled by OpenSSL as opposed to managing them from the Xrootd side; the only blocking is, once an hour, decrementing a refcount and doing an atomic update of a pointer location. Looking at the glibc implementation of the read-write, it seems the cost of the 'read lock' is an atomic increment except in the case when there's a pending write (which again, happens once an hour).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1