Apply CURL_CA_BUNDLE environment variable in the S3 backend too - #2069
Conversation
Refactor the repeated trivial CURLOPT setting into a subroutine, and additionally reinstate setting CURLOPT_CAINFO via the curl(1) tool's CURL_CA_BUNDLE environment variable, which the S3 code previously listened to via hfile_libcurl.c. Signed-off-by: John Marshall <jmarshall@hey.com>
Failure results in CURLE_FAILED_INIT, for which easy_errno() calls curl_easy_strerror(). There's no need to do anything complex here anyway. Signed-off-by: John Marshall <jmarshall@hey.com>
|
Added a second one-liner to make hfile_libcurl.c handle |
|
Thanks. Out of interest, how did |
|
I suspected that might pique your interest… 😄 Python wheels like to bundle the more exotic system libraries to make themselves portable across Linux distros. For a constellation of reasons (not least that this bundling is IMHO misguided), I'm changing pysam to omit libcurl and libcrypto — and the dozen others they drag in — from its wheels by dynamically loading them. (Sadly even building hfile_libcurl.so et al as htslib plugins wasn't enough to defeat the bundling machinery.) So I have a wrapper around So technically it wasn't the real (BTW I've since refactored it to set up libcurl and libcrypto separately.) This means that I won't be merging pysam-developers/pysam#1415 so pysam doesn't have an urgent need for the first commit of this PR after all. However it's still good to reinstate the CURL_CA_BUNDLE functionality for S3. |
|
Ah, yes. I thought it might be something related to library loading. |
Refactor the repeated trivial CURLOPT setting into a subroutine, and additionally reinstate setting CURLOPT_CAINFO via the curl(1) tool's CURL_CA_BUNDLE environment variable, which the S3 code previously listened to via hfile_libcurl.c code.