From: Patrick Ohly <patrick.ohly@intel.com>
To: "Blaettler, Michael" <michael.blaettler@siemens.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
"André Draszik" <git@andred.net>
Subject: Re: curl-native and ca-bundle
Date: Mon, 24 Oct 2016 15:14:19 +0200 [thread overview]
Message-ID: <1477314859.21499.20.camel@intel.com> (raw)
In-Reply-To: <347AAC56F29ACA4EA31B39C2109A6FE702F1298D@DEFTHW99EH2MSX.ww902.siemens.net>
On Mon, 2016-10-24 at 07:20 +0000, Blaettler, Michael wrote:
> Hi all
>
> We just had an issue in regard to curl-native.
> By default curl is configured with the "--with-ca-bundle=${sysconfdir}/ssl/certs/ca-certificates.crt" flag.
> In case curl-native is builded the ${sysconfdir} of the current project is compiled into the binary. Due to sstate caching the binary will be reused in other projects, but the ca-bundle is still loaded from the first project. As soon as the first project (where the initial build took place) is deleted, curl-native won't be able to fetch from HTTPS sources, because the ca-path is invalid.
>
> As a quick solution I removed the "--with-ca-bundle" configure option in native builds and curl is now loading the default certificate chain of the build host.
>
> Does anybody found simmilar issues in other recipes?
Yes, we ran into the same issue with a CVE check tool, which also uses
libcurl.
> How do you handle them?
We had to patch the tool so that it can override the CA cert path and
then explicitly override the builtin path at runtime, see:
https://github.com/01org/meta-security-isafw/commit/d844f370d5847da08fef83b916e621ebf6b5fa37
Some colleagues recently noticed that the version of cve-check-tool in
OE-core lacks that patch. I'm not sure whether that was reported,
though. André, Ismo?
> Is there a common approach?
No, not really. Patching binaries was mentioned, but it wasn't clear how
to do that in practice.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2016-10-24 13:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 7:20 curl-native and ca-bundle Blaettler, Michael
2016-10-24 13:14 ` Patrick Ohly [this message]
2016-10-25 5:49 ` Blaettler, Michael
2016-10-25 9:32 ` Patrick Ohly
2016-10-26 6:20 ` Blaettler, Michael
2016-10-26 6:41 ` Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1477314859.21499.20.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=git@andred.net \
--cc=michael.blaettler@siemens.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.