Print

---

@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, 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