On 06/16/17 01:38, coypu%sdf.org@localhost wrote:
I think we need to should teach curl to look in the right place.
It appears it has an option --with-ca-fallback=yes which might have the
expected behaviour, as it comes with the description:
checking whether to use builtin CA store of SSL library...
(So something like ``CONFIGURE_ARGS+= --with-ca-fallback=yes'' in curl's
makefile, and verifying that this line changes from 'no' to 'yes')
it looks like it will use openssl's code and certificates to validate if
an earlier option doesn't work.
And being a functional change, bump PKGREVISION :-)
If that fails we can pass it a CA_PATH, pkgsrc/*/mozilla-rootcerts
SSLDIR might contain the right logic for where the certificates are
expected to be.
Neither --with-ca-fallback=yes (verified in config.log) nor
--with-ca-path=/etc/ssl/certs (in place of --with-ca-path=${SSLCERTS})
seemed to have any effect.
I can work around it using --with-ca-bundle=/etc/ssl/certs/ca-bundle.crt.
I'm curious why --with-ca-path doesn't work. I verified the change in
config.log.
$ ./configure --with-ssl=/home/bacon/Pkgsrc/pkg-2017Q1
--with-ca-path=/etc/ssl/certs
--with-zlib=/home/bacon/Pkgsrc/pkg-2017Q1 --enable-ipv6
--without-libssh2 --without-gssapi --disable-ldap --without-librtmp
--with-libidn --without-nghttp2 --prefix=/home/bacon/Pkgsrc/pkg-2017Q1
--build=x86_64-redhat-linux --host=x86_64-redhat-linux
--mandir=/home/bacon/Pkgsrc/pkg-2017Q1/man