@abh3 - to be clear, I only hooked up the `XrdTpc` pieces. Here's the relevant locations:
- New `XrdTlsTempCA` object created: https://github.com/xrootd/xrootd/pull/1431/files#diff-c88246e4a0d4f2c51589397e8524f801b01a0c8003d011722c8901b960d1937eR82
- CA Guard handle obtained here: https://github.com/xrootd/xrootd/pull/1431/files#diff-2b4addbbda3815f5b12ae79ea8c5b7a9a4c89bfc7fbd160528a2811b091c70fcR107 (the reference has to be kept alive until libcurl is guaranteed to be done with it).
If we want to do the same thing for the other consumers of XrdTls, we'd need something that controls lifetime -- for XrdTpc, this is self-container because we know the libcurl handle will last precisely no longer than the synchronous function call. XrdHttp could, for example, have a static `shared_ptr` that is updated from a common `XrdTlsTempCA` object every hour. Do be careful about lifetime restrictions: if the shared pointer ever falls out of scope, then it's possible the OS will clean up the CA/CRL files.
For the configuration language -- this is essential for at least the NSS backend, so I hadn't planned to expose it as an option. I can see that it really should be an option for other users of XrdTls (where NSS isn't as problematic!).
I like this variant you suggest:
```
xrd.tlsca noverify | {certdir | certfile [auto]} path
```
Note in the current implementation the auto-generated CA file *only* works with the `certdir` and is superseded by `certfile` if set. Do you think we should do this regardless for XrdTpc, even if not explicitly requested?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/pull/1431#issuecomment-811614412
########################################################################
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
