@bbockelm commented on this pull request.

In src/XrdUtils.cmake:

> @@ -67,6 +67,25 @@ add_library(
   XrdTls/XrdTlsNotaryUtils.icc  XrdTls/XrdTlsNotaryUtils.hh
   XrdTls/XrdTlsPeerCerts.cc     XrdTls/XrdTlsPeerCerts.hh
   XrdTls/XrdTlsSocket.cc        XrdTls/XrdTlsSocket.hh
+  XrdTls/XrdTlsTempCA.cc        XrdTls/XrdTlsTempCA.hh
+
+  #-----------------------------------------------------------------------------
+  # XrdCrypto: linking against a few functions that are useful for XrdTls; avoids
+  # linking against all of libXrdCryptossl in XrdUtils

My presumption is that at the time gsi was written there could be a choice of which crypto functions could be used

My understanding is this was written "just in case" some other backend (like libnss) would come along and be a pluggable replacement to OpenSSL. Personally, I think making a generic plugin mechanism "just in case" is more effort than just writing two implementations... anyhow, past is past.

I don't think there's any problem in EPEL to compile twice here -- with EPEL, the usual concern is "vendoring" where you compile in a 3rd party package instead of depending on it as a separate RPM.

Since there's nothing to do currently, I'll just resolve this thread.

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

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/pull/1431#discussion_r603735248", "url": "https://github.com/xrootd/xrootd/pull/1431#discussion_r603735248", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

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