 |
 |
Hi Brian, Ah yes, I lost that email. So, is it the case that creating an ssl context also loads teh CRL's for that context. Thus, any time I create a new context I will get a fresh set of CRL's for that context. Anyway, let me inspect the code you pointed to. It will be part of the super merge into vomsxrd to have one thing to support. Andy On Tue, 21 Apr 2020, Brian P Bockelman wrote: > I wrote some tips to the mail list a few days back; copied here for reference: > >> ... >> >> Particularly, the singleton SSL_CTX* here: >> >> https://github.com/xrootd/xrootd/blob/master/src/XrdHttp/XrdHttpProtocol.cc#L1659 >> >> holds a pointer to a X509_STORE object. This object loads the CRLs at initialization but never reloads them. The SSL_CTX* is passed to libvomsapi through the callback registered by libXrdHTTPVOMS; in a finite amount of time, the CRLs expire. >> >> An example of loading a new X509_STORE is here: >> >> https://github.com/opensciencegrid/xrootd-lcmaps/blob/master/src/GlobusSupport.cc#L295 >> >> Unfortunately, to be able to know when you can safely delete the old object, you either need a stop-the-world global mutex wrapping the object or you can hash a few across threads as in here: >> >> https://github.com/opensciencegrid/xrootd-lcmaps/blob/master/src/GlobusSupport.cc#L354 >> >> In that example, we only lock across 1/63 of the threads when we are reloading. > > Brian > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/issues/750#issuecomment-617167381 -- 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-617367825 ######################################################################## 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