While debugging an issue why dev-php/composer fails with > [Composer\Downloader\TransportException] > curl error 77 while downloading https://repo.packagist.org/packages.json: Problem with the SSL CA cert (path? access rights?) I noticed that Composer is setting "cafile" to "CURLOPT_CAINFO" and "capath" to "CURLOPT_CAPATH" (https://github.com/composer/composer/blob/2.0.9/src/Composer/Util/Http/CurlDownloader.php#L61-L62). To quote cURL documentation (https://curl.se/libcurl/c/CURLOPT_CAINFO.html): > If CURLOPT_SSL_VERIFYPEER is zero and you avoid verifying the server's > certificate, CURLOPT_CAINFO need not even indicate an accessible file. > > This option is by default set to the system path where libcurl's cacert > bundle is assumed to be stored, as established at build time. > > If curl is built against the NSS SSL library, the NSS PEM PKCS#11 module > (libnsspem.so) needs to be available for this option to work properly. > Starting with curl-7.55.0, if both CURLOPT_CAINFO and CURLOPT_CAPATH are > unset, NSS-linked libcurl tries to load libnssckbi.so, which contains a > more comprehensive set of trust information than supported by nss-pem, > because libnssckbi.so also includes information about distrusted > certificates. This will not just affect dev-lang/php -- this will affect any application linking against cURL using built-in defaults. So I think net-misc/curl[curl_ssl_nss] should pull in dev-libs/nss-pem.
*** Bug 743995 has been marked as a duplicate of this bug. ***
(In reply to Thomas Deutschmann from comment #0) > So I think net-misc/curl[curl_ssl_nss] should pull in dev-libs/nss-pem. Currently I am using ca-certificates. RDEPEND=" ... ssl? ( ... nss? ( dev-libs/nss:0[${MULTILIB_USEDEP}] app-misc/ca-certificates ) ) " Why doesn't dev-lib/nss pick up on that? I'm cc-ing the mozilla team to give me some insight here.
I am also on Mozilla team. Let me try to answer: dev-libs/nss itself provides its own trust store. Firefox and Thunderbird are known examples which aren't using system certificate store and rely on certificates provided by nss. Therefore it would be wrong to pull in dev-libs/nss-pem with dev-libs/nss. But you are using dev-libs/nss with system certificate store which will require dev-libs/nss-pem.
(In reply to Thomas Deutschmann from comment #3) > I am also on Mozilla team. Let me try to answer: > > dev-libs/nss itself provides its own trust store. Firefox and Thunderbird > are known examples which aren't using system certificate store and rely on > certificates provided by nss. > > Therefore it would be wrong to pull in dev-libs/nss-pem with dev-libs/nss. > > But you are using dev-libs/nss with system certificate store which will > require dev-libs/nss-pem. Are you suggesting the following? nss? ( dev-libs/nss:0[${MULTILIB_USEDEP}] dev-libs/nss-pem app-misc/ca-certificates ) My concern is that nss-pem is not stable on any system and is only keyworded for amd64 and arm64. Can you advise?
Yes, that is my suggestion. I filed a keyword request for dev-libs/nss-pem, bug 769578.
(In reply to Thomas Deutschmann from comment #5) > Yes, that is my suggestion. > > I filed a keyword request for dev-libs/nss-pem, bug 769578. Okay, I'll add this after the keywording is done.
Just encountered a problem / side-effect of this issue trying to pull the flutter public git repo over https with net-misc/curl-7.79.1 installed. e.g. > fatal: unable to access 'https://github.com/flutter/flutter.git/': > Problem with the SSL CA cert (path? access rights?) So, first: net-misc/curl USE="nss -openssl" CURL_SSL="nss" works. net-misc/curl USE="nss openssl" CURL_SSL="nss" fails. However, as described here: net-misc/curl USE="nss openssl" CURL_SSL="nss" *and* installing dev-libs/nss-pem ... also fixes the issue. So there seems to be more than one option, depending on use case. Users should be stopped from installing curl with conflicting use flags and/or nss-pem needs to be drawn in if +nss is on.
(In reply to Anthony Basile from comment #6) > (In reply to Thomas Deutschmann from comment #5) > > Yes, that is my suggestion. > > > > I filed a keyword request for dev-libs/nss-pem, bug 769578. > > Okay, I'll add this after the keywording is done. Keywording is done, can you have a look?
(In reply to Sam James from comment #8) > (In reply to Anthony Basile from comment #6) > > (In reply to Thomas Deutschmann from comment #5) > > > Yes, that is my suggestion. > > > > > > I filed a keyword request for dev-libs/nss-pem, bug 769578. > > > > Okay, I'll add this after the keywording is done. > > Keywording is done, can you have a look? Now dev-libs/nss-pem needs keywording on riscv. I'll work on that and then commit the change in proposed in comment #4.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=49bf70035d505816abbb3b3d24d696bbd8da17d7 commit 49bf70035d505816abbb3b3d24d696bbd8da17d7 Author: Anthony G. Basile <blueness@gentoo.org> AuthorDate: 2022-09-05 16:34:48 +0000 Commit: Anthony G. Basile <blueness@gentoo.org> CommitDate: 2022-09-05 16:35:34 +0000 net-misc/curl: depend on dev-libs/nss-pem when CURL_SSL=nss Closes: https://bugs.gentoo.org/768912 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Anthony G. Basile <blueness@gentoo.org> net-misc/curl/{curl-7.85.0-r1.ebuild => curl-7.85.0-r2.ebuild} | 1 + 1 file changed, 1 insertion(+)