From: Patrick Ohly <patrick.ohly@intel.com>
To: "Blaettler, Michael" <michael.blaettler@siemens.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: curl-native and ca-bundle
Date: Wed, 26 Oct 2016 08:41:27 +0200 [thread overview]
Message-ID: <1477464087.2887.22.camel@intel.com> (raw)
In-Reply-To: <347AAC56F29ACA4EA31B39C2109A6FE702F13188@DEFTHW99EH2MSX.ww902.siemens.net>
On Wed, 2016-10-26 at 06:20 +0000, Blaettler, Michael wrote:
> 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.
Quite the opposite, it leads exactly to the problem that I feared.
Suppose you build on distro foo where the configure script finds and
thus hardcodes in the binary ca=/etc/ssl/certs/ca-certificates.crt. Then
you build on distro bar which has /etc/pki/tls/certs/ca-bundle.crt
instead. When using uninative, it is likely that compiling curl-native
anew will be skipped and instead curl-native gets installed from the
sstate that was prepared on distro foo. The result is a curl-native that
doesn't have SSL certificates and thus https will not work.
--
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.
prev parent reply other threads:[~2016-10-26 6:41 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
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 [this message]
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=1477464087.2887.22.camel@intel.com \
--to=patrick.ohly@intel.com \
--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.