[XrootdHttpTPC] Empty CRL file fails a HTTP TPC pull transfer

[ccaffy]

Hello,

After the submission of an HTTP TPC Pull transfer, I got the following error client side:

* Connection #0 to host xrootd-ccaffy-dev01.cern.ch left intact
failure: Failed to load CRL file (path? access rights?, format?)[xrootddev@xrootd-ccaffy-dev01 xrootd-run]$ 

On server side:

211027 15:06:03 32354 TPC_PullRequest: event=TRANSFER_FAIL, local=/tmp/tpcfile1, remote=https://eospps.cern.ch/eos/user/ccaffy/file1, user=(anonymous), bytes_transferred=0; HTTP library failure: Failed to load CRL file (path? access rights?, format?)

Here is the configuration file I have:

all.export /tmp nolock
all.adminpath  /var/spool/xrootd
xrd.port 1095
ofs.tpc autorm ttl 7 15 xfr 9 pgm /home/xrootddev/xrootd-run/my_xrdcp.sh
xrd.tls /etc/grid-security/xrd/xrdcert.pem /etc/grid-security/xrd/xrdkey.pem
xrd.tlsca certdir /etc/grid-security/certificates
http.exthandler xrdmacaroons libXrdMacaroons-5.so
macaroons.secretkey /etc/xrootd/macaroon-secret
ofs.authlib libXrdMacaroons-5.so
if exec xrootd
  xrd.protocol http:1095 libXrdHttp-5.so
  http.exthandler xrdtpc libXrdHttpTPC-5.so
  http.secxtractor libXrdVoms-5.so
fi
all.sitename xrootddev

After debugging the xrootd process, I could see that curl complains with "Failed to load CRL file (path? access rights?, format?)"
when the CURLOPT_CRLFILE option points to an empty file.

The workaround I found was to set the following environment variable:

export XRDTPC_CADIR=/etc/grid-security/certificates/

This prevents the class XrdTlsTempCA from being instanciated and therefore prevents to
set the CURLOPT_CRLFILE option (done by the method TPCHandler::ConfigureCurlCA()).

In my opinion, this can be problematic for users. The directory where the certificates
are located is passed via the configuration of the server. If a user has no CRL file on the certificate directory, XRootD should
just ignore it and should not try to set the CURLOPT_CRLFILE curl option.

In production, everything works fine because the concatenated CRL file is not empty:

[root@eospps-fe1 (mgm:master mq:master) ~]$ cat /tmp/mgm/.xrdtls/crl_file.pem | wc -l
12518

My first question is, is it me who wrongly configured the server?

Otherwise, should we add a check that verifies that the concatenated CRL file is not empty before assigning it to CURLOPT_CRLFILE ?

@abh3 , @bbockelm what is your opinion about this issue?

Thanks in advance for your answers :)

Cheers,
Cedric

[bbockelm]

Hi,

In "grid world", CRLs are often mandatory. In the remainder of the planet, CRLs are rarely (never might be too strong?) mandatory.

I would prefer to go the "remainder of the planet" route. Can you submit a PR?

Does it error if the file is 1-byte long? Or does it error whenever there are zero valid CRLs?

Brian

[ccaffy]

I also prefer the remainder of the planet :)

Yes, I will take a look at this and submit a PR.

For this I need to try. I will answer your question in this ticket :)

[ccaffy]

Does it error if the file is 1-byte long? Or does it error whenever there are zero valid CRLs?

An error is triggered if there is no valid CRL in the aggregated-CRL file or if it is empty.

[ccaffy]

After the discussions on #1547
If no CRL file has been written to the concatenated-CRL file, the CURLOPT_CRLFILE should not be set.
I will implement this behaviour