| Summary: | curl-native: invalid builtin ca-bundle path when restoring from sstate | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Patrick Ohly <patrick.ohly> |
| Component: | core | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | jku, meta.mr.watcher, meta.watcher, p.lobacz, pascal.bach, paul, phil, ross.burton, sgw, tim.orling |
| Version: | 2.1 | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 9242 | ||
| Bug Blocks: | |||
In the long term bug 9242 is hopefully the solution here. In the short term, the caller should tell curl where to look. Our solution for this problem was to just not hardcode the path in the native version. This means it will fall back to the host ca-certificates. Might this be an acceptable solution for upstream? This bug became more visible with recipe-specific sysroots: The sysroot that native libcurl refers to is its own sysroot: it is very likely to not exist when used from a binary in another sysroot. I'll send a patch to use host certs for native, but other options are welcome too. (In reply to comment #3) > This bug became more visible with recipe-specific sysroots: > The sysroot that native libcurl refers to is its own sysroot: it is very > likely to not exist when used from a binary in another sysroot. > > I'll send a patch to use host certs for native, but other options are > welcome too. The path to the host certs is not the same when moving the binary from one host machine to another via sstate reuse, i.e. that approach does not solve the problem completely. I'm not sure whether an interim solution is useful. I myself would prefer a proper solution, even if it is harder to implement. (In reply to comment #4) > The path to the host certs is not the same when moving the binary from one > host machine to another via sstate reuse, i.e. that approach does not solve > the problem completely. This is true... I've ported your --cacert patch for cve-check-tool so the immediate need is no longer there for me either. We hit this problem with the OSTree uploader in meta-updater. I think 'right' solution for us is to be explicit about the CA certificates, either by including the relevant root CA in the credentials bundle sent to the client (aka certificate pinning) or by depending on ca-certificates explicitly in the uploader.
Removing the hard-coded path in curl-native would at least force everyone to face this up-front, but might break too much existing (mostly) working code.
What about including ${sysconfdir}, and thus the ca-certificates path in the SSTATE cache key calculation? This would stop (possibly invalid) cache hits in the case where people are sharing the sstate cache between machines.
I just hit this again. Not entirely certain it is only sstate related. The issue came up when building a recipe where and npm module (zeromq@6.0.0-beta.16) needs to download a tarball from https://github.com In my case, a workaround was to add the following to the recipe which needed
curl https during do_compile():
+# Needed for npm to be able to curl https://
+DEPENDS += "ca-certificates-native"
+export CURL_CA_BUNDLE="${STAGING_DIR_NATIVE}${sysconfdir_native}/ssl/certs/ca-certificates.crt"
+
In my case the isssue is more complicated I don't even have this ca-certificates.crt in curl-native/7.82.0-r0/recipe-sysroot-native/etc/ssl/certs path which is odd... We discussed this on the bug triage call as it's been inactive for so long. The issue is that default paths are hardcoded into openssl during build and it's not possible to relocate them when restoring sstate into a different build path. We've tried to get this fixed upstream (https://github.com/openssl/openssl/pull/19260) but progress has stalled. Help is wanted to get this moving again with openssl. |
--with-ca-bundle=${sysconfdir}/ssl/certs/ca-certificates.crt in curl_7.41.1.bb causes the current build host's sysroot path to be compiled into libcurl. That path is not necessarily valid when restoring that library from sstate on another host, which then causes SSL certificate validation to fail due to the missing ca-certificates.crt file. Restoring from sstate should patch this string (best solution?) or some environment variable should be checked to override the invalid path at runtime (but then invoking tools which use this libcurl must always be done with that env variable set, which is not guaranteed when some user calls them directly outside of bitbake).