9883 2016-07-06 08:41:47 +0000 curl-native: invalid builtin ca-bundle path when restoring from sstate 2026-01-22 16:31:01 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.1 x86 Multiple NEW Medium+ normal Future 9242 1 patrick.ohly unassigned jku meta.mr.watcher meta.watcher p.lobacz pascal.bach paul phil ross.burton sgw tim.orling --- --- No (bug/feature does not impact docs) oldest_to_newest 63665 0 patrick.ohly 2016-07-06 08:41:47 +0000 --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). 63727 1 ross.burton 2016-07-07 15:10:31 +0000 In the long term bug 9242 is hopefully the solution here. In the short term, the caller should tell curl where to look. 67479 2 pascal.bach 2016-10-24 14:02:13 +0000 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? 70503 3 jku 2017-02-07 17:27:43 +0000 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. 70504 4 patrick.ohly 2017-02-07 17:38:25 +0000 (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. 70600 5 jku 2017-02-09 18:12:16 +0000 (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. 71201 6 phil 2017-03-13 07:46:44 +0000 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. 95627 7 tim.orling 2023-06-02 21:44:19 +0000 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 95628 8 tim.orling 2023-06-03 16:37:11 +0000 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" + 97217 9 p.lobacz 2023-11-07 15:46:13 +0000 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... 104037 10 paul 2026-01-22 16:31:01 +0000 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.