Bug 16077 - opkg in SDK fails to validate server certificates
Summary: opkg in SDK fails to validate server certificates
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: oe-core other (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 5.0.15
Assignee: Moritz Haase
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2025-11-26 12:47 UTC by Moritz Haase
Modified: 2025-12-22 10:32 UTC (History)
2 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Haase 2025-11-26 12:47:00 UTC
Change https://git.openembedded.org/openembedded-core/commit/?id=4909a46e93ba774c960c3d3c277e2a669af3fea6 (or more specifically, it's backport to Scarthgap) has broken opkg in the SDK for us: It now fails to download
packages via HTTPS (from a server with a "proper" certificate from a public CA),
reporting:

> SSL certificate problem: self-signed certificate in certificate chain

It looks like the env variables set by [0] and others like 'SSL_CERT_(DIR|FILE)'
(see [1]) are only taken into account by curl on the command line (see [2]), but
not by libcurl, which opkg uses. Removing the default CA bundle option from the
build now means that libcurl doesn't have any CA certificates to verify against
unless explicitly configured (previously it was using 'ca-certificates.crt'
shipped by the SDK). Since opkg doesn't have any env var handling built-in,
it ends up without a CA bundle and fails to verify certificates.

Based on a discussion on the mailing list, the workaround suggested in [3] seems to be the best course of action to fix this and still respect host settings. It'd mean that there is a sensible default of using the host system's bundle for verification for all programs using libcurl (unless they implement their own override mechanisms).

[0]: https://git.openembedded.org/openembedded-core/tree/meta/recipes-support/curl/curl/environment.d-curl.sh
[1]: https://git.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/files/environment.d-openssl.sh
[2]: https://github.com/curl/curl/blob/de7b3e89218467159a7af72d58cea8425946e97d/src/tool_operate.c#L2586-L2623
[3]: https://lists.openembedded.org/g/openembedded-core/topic/115993530#msg226756
Comment 1 Moritz Haase 2025-11-26 12:47:39 UTC
I'm currently preparing a patch with the aforementioned fix for submission to the mailing list.
Comment 2 Moritz Haase 2025-11-28 06:25:11 UTC
Patch has been submitted to the mailing list for 'master': https://patchwork.yoctoproject.org/project/oe-core/patch/20251127103129.2564918-1-Moritz.Haase@bmw.de/
Comment 3 Randy MacLeod 2025-12-02 19:43:15 UTC
Merged so resolving:
   https://git.openembedded.org/openembedded-core/commit/?id=545e43a7a45be02fda8fc3af69faa20e889f58c4

❯ git branch -a --contains 545e43a7a45be02fda8fc3af69faa20e889f58c4
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/master-next

Thanks Moritz!
Comment 4 Moritz Haase 2025-12-03 06:35:20 UTC
@Randy: Looks like there has been a minor mix-up and the ticket will need to be re-opened. My commit that got merged and that you linked to ("curl: Ensure 'CURL_CA_BUNDLE' from host env is indeed respected") is related, but not the actual fix. That'd be "curl: Use host CA bundle by default for native(sdk) builds" (linked in my previous comment), which hasn't been accepted yet.
Comment 5 Randy MacLeod 2025-12-04 00:54:52 UTC
Moritz,
Oops, my bad.
Thanks for correcting the situation.
I'll leave resolution of this bug to you but I've moved it to "IN PROGRESS DESIGN" since it is in that state.
../Randy
Comment 6 Moritz Haase 2025-12-22 10:32:19 UTC
Actual fix has now been merged:

https://git.openembedded.org/openembedded-core/commit/?id=3f819f57aa1960af36ac0448106d1dce7f38c050

❯ git branch -a --contains 3f819f57aa1960af36ac0448106d1dce7f38c050
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/master-next