pkgxdev
git ignores `sshCAInfo` certificate location
When adding a custom CA ceritficate via git config --global http.sslCAInfo /tmp/git.pem, corresponding SSL certificates are still not accepted. It seems git relies completely on curl for that and is not respecting this setting.
With the system git (v2.43.0; Ubuntu 24.04) it works as expected.
Maybe related to #1219?
@ralfschulze if you comment out GIT_SSL_CAINFO: '{{deps.curl.se/ca-certs.prefix}}/ssl/cert.pem' in your pantry's projects/git-scm.org/package.yml, does that allow it to respect the config setting? if so, we can probably put some code into git-shim which will check the config, and unset that env var if you've configured your own.
Yes, then the setting is respected.
The solution is maybe not quite so easy. You can set the sslCAInfo setting for domain patterns, so git will use the configured cert only for the configured domains and relies on the certificate store for the rest.
Btw: It think there should be a build dependency for gcc in the package.yml.
Sounds like the shim should check git config. It'll slow it down, but it's the way.
Build defaults to llvm on Linux and xcode on Darwin, so a gcc dependency is only needed if those don't work.
ok, we're closing in. If you make the edit in #10034 to your ~/.pkgx/git-scm.org/v*/bin/git script, does that fix your issue (it seems to work for me).
if so, I'll rebuild our git bottles so they all have it.
I don't think this is a good solution.
E.g. this will not work:
[http "https://*.mycompany.com"]
sslCAInfo = /tmp/cert.pem
git config --get http.sslCAInfo will return nothing in this case, so the variable stays in place. It is not fixed for this common situation, where you just want to provide a certificate for some special servers and use "default" certs for anything else.
Honestly I do not like the idea of bringing in a new certificate store at all. All major OS have a system store and usually you configure your 'special' CAs in this system certificate store. Yet another store just makes things more complicated (and surprising). Hardly a good idea for security related stuff. I also would not know how I easily and reliably can remove untrusted certs from the delivered certificate store that came with pkgx curl. And do I have to do this for all other pkgx packages manually also? Does wget also deliver its own store?
This was exactly the situation I was coming from: My system git knew my company CA certificate, because it was configured system wide. pkgx git did not, which made me discover the whole situation with sslCAInfo.
We should treat trusted certificates as configuration. There is a default from the OS, but I can change it when I want and ideally all my programs only trust the CAs in my config.
So I suggest to just remove the GIT_SSL_CAINFO and we should be fine.
The issue arises because bare Linux systems have no certificate store installed by default, and pkgx tools are intended to be self-sufficient.
I'm happy to consider other fixes that take this into account.
We could have the environment respect an outside env var if present. That would make it easy to override.
What about a separate package ca-certificates that all other packages are using. To override and fall back to the system store the ca-certificates package should provide a config option (environment variable?).
Still: This would not solve the git issue and maybe similar issues for other packages.
Yes, there's two problems.
Putting some intelligence into curl.se/ca-certs would be interesting. I'll ponder it, but if you have ideas, I'm happy to look at them.
I have given it some thought. Usually there will be a system certificate store, which may be groomed by a careful admin to include custom certificates and exclude those which he does not trust. I think this should be the default store to use as it will be least surprising, convenient and probably also the most secure solution. There is no unexpected switching between certificate stores. Also then we can leave the ca cert configuration of most delivered apps alone, which should avoid bugs like this one.
For the cases where there is now system certificate store (e.g. slim containers) the user can install curl.se/ca-certs manually and configure it via environment variables to be the primary store (e.g. SSL_CERT_FILE, which seems to be respected by openssl).
This seems to be the way the nix package manager is doing it.