 |
 |
@bbockelm commented on this pull request. > @@ -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 or view it on GitHub: https://github.com/xrootd/xrootd/pull/1431#discussion_r603735248 ######################################################################## 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