git no longer falls back to system SSL certificate store in Alpine 3.21

I attempted to recompile git-2.48.1-r0 on alpine:3.20, and I didn't run into the issue.

However, on alpine:3.21, I still ran into this issue after I built and installed git-2.48.1-r0.

curl has a --with-ca-fallback option that might help with this, but it's not on by default. In https://build.alpinelinux.org/buildlogs/build-edge-x86/main/curl/curl-8.12.1-r0.log, I see this is not enabled:

  ca cert bundle:   /etc/ssl/cert.pem
  ca cert path:     no
  ca cert embed:    no
  ca fallback:      no

I'm not sure if this were enabled at some point because the job logs are archived.

On Alpine 3.20, if I rebuild curl 8.12.1-r0 and install this package over the current version, I see this error.

The same happens if I rebuild the package --with-ca-file.

Ah, I see this is the diff between 3.20 and 3.21 even though the curl version is the same:

% git diff origin/3.20-stable origin/3.21-stable main/curl
diff --git a/main/curl/APKBUILD b/main/curl/APKBUILD
index 738cf9f33d8..f392f140e47 100644
--- a/main/curl/APKBUILD
+++ b/main/curl/APKBUILD
@@ -14,7 +14,7 @@ pkgdesc="URL retrival utility and library"
 url="https://curl.se/"
 arch="all"
 license="curl"
-depends="ca-certificates"
+depends="ca-certificates-bundle"
 depends_dev="
        brotli-dev
        c-ares-dev
@@ -29,10 +29,14 @@ checkdepends="nghttp2 python3"
 makedepends_host="$depends_dev"
 makedepends_build="groff perl"
 subpackages="$pkgname-dbg $pkgname-static $pkgname-doc $pkgname-dev libcurl"
-[ -z "$BOOTSTRAP" ] && subpackages="$subpackages $pkgname-zsh-completion $pkgname-fish-completion"
+if [ -z "$BOOTSTRAP" ] && [ -z "$APORTS_BOOTSTRAP" ]; then
+       subpackages="$subpackages $pkgname-zsh-completion $pkgname-fish-completion"
+fi
 source="https://curl.se/download/curl-$pkgver.tar.xz"
 options="net" # Required for running tests
-[ -n "$BOOTSTRAP" ] && options="$options !check" # remove python3 dependency
+if [ -n "$BOOTSTRAP" ] || [ -n "$APORTS_BOOTSTRAP" ]; then
+       options="$options !check" # remove python3 dependency
+fi

 # secfixes:
 #   8.12.0-r0:
@@ -213,6 +217,7 @@ build() {
                --with-libidn2 \
                --with-nghttp2 \
                --with-openssl \
+               --with-ca-bundle=/etc/ssl/cert.pem \
                --with-zsh-functions-dir \
                --with-fish-functions-dir \
                --disable-ldap \
@@ -222,7 +227,7 @@ build() {
        make

        # generation of completions is not supported when cross-compiling.
-       if [ -z "$BOOTSTRAP" ]; then
+       if [ -z "$BOOTSTRAP" ] && [ -z "$APORTS_BOOTSTRAP" ]; then
                make -C scripts/
        fi
 }
@@ -237,7 +242,7 @@ package() {
        depends="libcurl=$pkgver-r$pkgrel"

        make install DESTDIR="$pkgdir"
-       if [ -z "$BOOTSTRAP" ]; then
+       if [ -z "$BOOTSTRAP" ] && [ -z "$APORTS_BOOTSTRAP" ]; then
                install -Dm644 scripts/_curl -t \
                        "$pkgdir"/usr/share/zsh/site-functions/
                install -Dm644 scripts/curl.fish -t \

Quite possibly the addition of --with-ca-bundle changed this behavior?

If I omit --with-ca-bundle I see that curl sets --with-ca-path to a reasonable value:

  ca cert bundle:   /etc/ssl/certs/ca-certificates.crt
  ca cert path:     /etc/ssl/certs
  ca cert embed:    no
  ca fallback:      no

@ncopa This is likely the key difference here. I'm not sure if shifting to ca-certificates-bundle for #16264 (closed) is a good idea for this reason. Alternatively, --with-ca-path could be set to /etc/ssl/certs?

mentioned in issue #16264 (closed)

I do not think the above #16264 (closed) i had opened is the root cause of whatever issue you have, on my Alpine edge box there is only Alpine stuff involved and it works just fine:

#?00.00 1/123|sdaoden:aports.git$ grep -E 'sslVer|sslTry' ~/.gitconfig
sslVerify = true
sslTry = true
#?00.00 1/123|sdaoden:aports.git$ grep upstream .git/config
[remote "upstream"]
        fetch = +refs/heads/master:refs/remotes/origin/upstream
        remote = upstream
#?00.00 1/123|sdaoden:aports.git$ env -i git ls-remote upstream|wc -l
4092
#?00.00 1/123|sdaoden:aports.git$ uname -a
Linux sdaoden.eu 6.12.18-0-virt #1-Alpine SMP PREEMPT_DYNAMIC 2025-03-06 14:17:54 x86_64 Linux

See the details above about how to reproduce the issue.

Note that when --with-ca-bundle is specified, curl does not try to auto-detect a reasonable value of --with-ca-path.

If the provided CA bundle doesn't match the server TLS certificates, then curl doesn't have a way to validate the root certificate using the hashed certificates in /etc/ssl/certs.

That's why I think either:

--with-ca-path should be supplied.
--with-ca-bundle should be omitted entirely so curl will set both values.

mentioned in merge request !81269 (merged)

That seems like a feature to me, actually. If you do specify an explicit CA, that one has to be it, no?

Maybe, both curl defaults to using both --cacert and --capath sources if available, so anyone who didn't set up their CA bundles perfectly will see their SSL connections fail.

There's also another reason why it's a good idea to prefer ca-certificates over ca-certificates-bundle: speed. As documented in https://curl.se/docs/manpage.html#--cacert, --capath is much more efficient at verifying certificates because curl can immediately look up a hashed value, whereas with only the --capath the file has to be parsed and then indexed.

I've submitted !81269 (merged) for now, but I personally think !69012 (merged) should be reverted.

mentioned in issue #16277

Speed i also would disagree with. Ie, the server or your browser (if SSL based) starts up, and the thing is loaded. Might be true for a single curl invocation, but then i claim the file is as hot as the OS filesystem cache can get, and it is always the same one. I have forgotten whether it is even mmap(2)able, or not (and i will not look now); but i have looked in the past, and the file is i think always looked up first (by OpenSSL). So if it is there, you pay.

And then i mean, if you have permanent local additions, you could add them to the global store; this is not so easy as simply placing a file in certs/, i admit that. Btw FreeBSD has a scripted CA root approach with automatic rehashing the files i think. I personally have something similar; it is less fancy, but there is a config which names local additions/removals, and whenever the Mozilla pool is updated, those local changes are worked to create the CA pool. (I think the FreeBSD people have a regular management script that root can use, i was a bit disappointed that they have not considered my script and so i have not truly looked; i always hated that hashed dir thing, even though somewhen, somewhere, i have seen a non-perl approach for the c_rehash script, but do not ask me no questions, i have forgotten. Ah, FreeBSD management script is called certctl(8), POSIX shell, and it can also rehash. You know, with that, maybe, but i personally go for the file.)

(Btw if you cross link even more issues, the speed improvement will be so hyper it blows the roof.)

(And really, look into OpenSSL code before you claim this. Iirc the file is always inspected first, if it exists.)

I stand corrected about the speed aspect. It looks like curl calls X509_STORE_load_file(store, ssl_cafile) and X509_STORE_load_path(store, ssl_capath) in sequence to populate the store. But that shows that the ssl_capath is the fallback mechanism in case whatever cert bundle is provided is not adequate, so !81269 (merged) makes sense.

closed with merge request !81269 (merged)

mentioned in merge request !81333 (merged)

git no longer falls back to system SSL certificate store in Alpine 3.21

Package Information

Summary

Steps to reproduce

`alpine:3.20`

`alpine:3.21`

Child items ...

Activity