[yocto] curl-native and ca-bundle

[Blaettler, Michael]

Hi Patrick

What do you think of removing the --with-ca-bundle as a solution for curl-native? On my machine it works without problems.
Might this be an acceptable solution for upstream?

Kind regards

Michael

-----Ursprüngliche Nachricht-----
Von: Patrick Ohly [mailto:patrick.ohly at intel.com] 
Gesendet: Montag, 24. Oktober 2016 15:14
An: Blaettler, Michael (BT CPS R&D ZG FW ITW)
Cc: yocto at yoctoproject.org; Ismo Puustinen; André Draszik
Betreff: Re: [yocto] curl-native and ca-bundle

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.