 |
 |
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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/750#issuecomment-617534058 ######################################################################## 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