[yocto] curl-native and ca-bundle

[Blaettler, Michael]

Hi Patrick

I just checked the source code of curl.

In acinclude.m4 on line 2560, you'll find:
dnl CURL_CHECK_CA_BUNDLE
dnl -------------------------------------------------
dnl Check if a default ca-bundle should be used
dnl
dnl regarding the paths this will scan:
dnl /etc/ssl/certs/ca-certificates.crt Debian systems
dnl /etc/pki/tls/certs/ca-bundle.crt Redhat and Mandriva
dnl /usr/share/ssl/certs/ca-bundle.crt old(er) Redhat
dnl /usr/local/share/certs/ca-root-nss.crt FreeBSD
dnl /etc/ssl/cert.pem OpenBSD, FreeBSD (symlink)
dnl /etc/ssl/certs/ (ca path) SUSE

Later in the function there's a for loop, searching every path for the certificate-chain (if --with-ca-bundle is not set).
for a in /etc/ssl/certs/ca-certificates.crt \
         /etc/pki/tls/certs/ca-bundle.crt \
         /usr/share/ssl/certs/ca-bundle.crt \
         /usr/local/share/certs/ca-root-nss.crt \
         /etc/ssl/cert.pem \
         "$cac"; do
    if test -f "$a"; then
        ca="$a"
        break
    fi
done

Regarding this configuration script, removing --with-ca-bundle in curl-native should not cause any problems.

Kind regards

Michael

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

On Tue, 2016-10-25 at 05:49 +0000, Blaettler, Michael wrote:
> 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.

What path does it use then? Something that configure determines based on the current machine (sorry, I'm lazy^Wbusy right now and haven't checked)?

I suspect that this won't work when moving the resulting lib through sstate from one Linux distro to another if the location of the bundle file is different on those two distros.

--
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.