I have an API package on CRAN that provides an interface with a United Nations DB (link to UN site), it's built using httr, which uses the curl package. I discovered yesterday that the core functions of my package were no longer working properly on Windows machines, they all fail with the error message:
Error in curl::curl_fetch_memory(url, handle = handle) :
Peer certificate cannot be authenticated with given CA certificates
Which basically means there's a CA certificate issue preventing curl from completing the connection. After looking into this a bit, I believe the UN site hosting the DB is the issue, its SSL certificate is invalid per ssldecoder (see this link).
One easy fix to circumvent this issue is to add param ssl_verifypeer = FALSE
to all calls to httr::GET()
. However this is not an ideal solution for security reasons, since it bascially tells curl to make the connection regardless of the validity of the site's certificate.
My question is, what is the consensus on using this parameter within a CRAN package? Keeping in mind that the UN website is (presumably) safe?
Via https://curl.haxx.se/docs/sslcerts.html:
Get a CA certificate that can verify the remote server and use the proper option to point out this CA cert for verification when connecting. For
libcurl
hackers:curl_easy_setopt(curl, CURLOPT_CAPATH, capath)
;
In R curl
options, that's capath
.
You can get recent versions of those here https://curl.haxx.se/docs/caextract.html provided you trust the main cURL site.
cacert.pem
=== ca-bundle.crt
if you happen to see references to both/either.
If updated CA files still cause the issue then you're doing a disservice to the user by having them think they're OK by just passing FALSE
to your functions.
I have no idea what harm data comtrade data integrity loss/manipulation would cause folks. But beyond that, a flagged cert cld also be a sign to the user of MITM. Either way, you should think twice about being an enabler.