Hotfix/2.0.8

[pmaciel]

Project packaging sometimes uses distributions to configure & build that have different default path locations to the target platforms. Specifically the (eckit dependency) CURL default CA bundle path does not exist on the distributed Python packages supporting Earthkit, which is intended for a very diverse audience. On failing to find the, CURL cannot verify the host/target connection to do SSL-based transfers.

Here proposed, if there are no (related) environment-controlling variables nor the internal default leads to an existing path, a series of path searches are attempted based on common, expected dirname and basename combinations, local path (".") is avoided for security reasons.

Unfortunately, no test is added because handling these paths are commonly permission-limited.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 94.11765% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 66.41%. Comparing base (dbc9c0f) to head (75cf0fa).

Files with missing lines	Patch %	Lines
src/eckit/io/EasyCURL.cc	94.11%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #287      +/-   ##
==========================================
+ Coverage   66.38%   66.41%   +0.03%     
==========================================
  Files        1127     1127              
  Lines       57792    57809      +17     
  Branches     4408     4414       +6     
==========================================
+ Hits        38365    38394      +29     
+ Misses      19427    19415      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[pmaciel]

In researching the MeteoSwiss failure a bit further and looking into CURL, the failure they see can be

1. TLS handshake fails (that could happen from failing to find a CA bundle, which this PR addresses)
2. DNS resolution failure
3. connection refused or timeout

So while this PR focuses on one of the two failures, it could solve both -- @iainrussell maybe it would be good to tell them directly to test this branch (somehow!), we don't have a testing environment

[Ozaq]

In researching the MeteoSwiss failure a bit further and looking into CURL, the failure they see can be

1. TLS handshake fails (that could happen from failing to find a CA bundle, which this PR addresses)
2. DNS resolution failure
3. connection refused or timeout

So while this PR focuses on one of the two failures, it could solve both -- @iainrussell maybe it would be good to tell them directly to test this branch (somehow!), we don't have a testing environment

This indicates that we need to improve the error message and communicate the underlying error.

[Ozaq]

ca-certs form the base of trust for TLS secured communication and thus the paths are set by the distribution. By picking up certs from additional locations we increase the possible attack surface.

Additionally this is a problem with a "well known" solution, i.e. setting the above mentioned env variables.

[Ozaq]

I think a much better approach is to follow what netcdf and Fiona are doing:

Both python projects solve this issue by using the 'certifi' package, essentially a ca store installed through pip.

They then go on and check if SSL_CERT_FILE or CURL_CA_BUNDLE is set (in earthkit) and configure eckit with the location (this code needs to be added.

This will change the behavior to: always use certs from certifi unless user overrides with env variables.

Pulling up the selection logic into earth kit is imo the right choice because this is the place where we are guratueed to know the location of a valid store (certifi)