https://git-annex.branchable.com/git-annex/ mentions
(The http.sslCAInfo and http.sslCAPath git configs have the same effect.)
but unfortunately it seems that there is no symmetric to git support for per-SITE settings, e.g.
(tmp) yoh@typhon:/tmp$ git clone https://datalad-test.local.lan/DLTC/sample_datalad_provider /tmp/my_clone
Cloning into '/tmp/my_clone'...
fatal: unable to access 'https://datalad-test.local.lan/DLTC/sample_datalad_provider/': server verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
can be overcome for git with
(tmp) yoh@typhon:/tmp$ openssl s_client -connect datalad-test.local.lan:443 </dev/null 2>/dev/null | openssl x509 > ~/.config/git-credential-diab/datalad-test.local.lan-ca.pem
(tmp) yoh@typhon:/tmp$ git config --global http.https://datalad-test.local.lan.sslCAInfo ~/.config/git-credential-diab/datalad-test.local.lan-ca.pem
(tmp) yoh@typhon:/tmp$ git clone https://datalad-test.local.lan/DLTC/sample_datalad_provider /tmp/my_clone
Cloning into '/tmp/my_clone'...
remote: Enumerating objects: 47, done.
remote: Counting objects: 100% (47/47), done.
remote: Compressing objects: 100% (38/38), done.
remote: Total 47 (delta 12), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (47/47), 4.33 KiB | 4.33 MiB/s, done.
Resolving deltas: 100% (12/12), done.
but for recent annex it remains "not good" (until we override for all sites):
(tmp) yoh@typhon:/tmp/my_clone$ git annex version --raw; echo
10.20260624-g1f50df25f767231afaf9de9119f4a339d0619256
(tmp) yoh@typhon:/tmp$ cd my_clone/
(tmp) yoh@typhon:/tmp/my_clone$ git annex whereis annexed_demo.bin
Remote origin not usable by git-annex; setting annex-ignore
https://datalad-test.local.lan/DLTC/sample_datalad_provider/config download failed: HandshakeFailed (Error_Protocol "certificate has unknown CA" UnknownCa)
whereis annexed_demo.bin (2 copies)
01486323-6af3-4c59-a372-dea7d9340f6d -- git@02915365b276:/data/git/repositories/dltc/sample_datalad_provider.git
a69e3dc7-4554-4aae-819f-c65b7dd414e9 -- datalad@datalad-kbdm-datalad-provider:/tmp/push_test
ok
(tmp) yoh@typhon:/tmp/my_clone$ git config --unset remote.origin.annex-ignore
(tmp) yoh@typhon:/tmp/my_clone$ git annex whereis annexed_demo.bin
whereis annexed_demo.bin (2 copies)
01486323-6af3-4c59-a372-dea7d9340f6d -- git@02915365b276:/data/git/repositories/dltc/sample_datalad_provider.git [origin]
a69e3dc7-4554-4aae-819f-c65b7dd414e9 -- datalad@datalad-kbdm-datalad-provider:/tmp/push_test
ok
# so no complains about ssl certificate and subsequent annex copy actually works out nicely
I got as far as implementing a git compatible config matcher, in 6f43e386788eb01e944f98df0d6ed6eb79b84e76.
But, it's difficult to see a way to implementing this for http.sslCAInfo and http.sslCAPath. It needs to somehow be fed into http-client's Manager. But a Manager is set up outside any code path that knows what url is being downloaded. And nothing in the Manager API lets it override its ConnectionContext based on the url being requested.
I think that UrlOptions would need to change httpMananger to an IO action that takes the url. And then to be performant, there would need to be caching of Managers, so that once a manager is created using a given http.sslCAInfo or http.sslCAPath, that same Manager keeps being used for other urls that use the same config values.
But the fun doesn't stop there, because Manager is a core data type used by other haskell libraries. Eg, in Remote.S3, git-annex passes a Manager into
aws, and so has no visibility about what urls that Manager will be used for.And that shades into another problem -- the
http.<url>.*documentation includes this:If git-annex follows that, it would need to distinguish when an url is user-provided enough to use that config and not.
When using Remote.GitLfs to download an object, there is essentially a redirect via the git-lfs protocol. Should that url be matched against the git config? Seemingly not. But in the aws case, the S3 publicurl= value was provided as an input to git-annex annex command. So it seems that it should.
What does it mean for the url to be given directly to a git(-annex) command? The
git cloneurl certianly was. The S3 publicurl= value was provided by someone but it may not be the user using the remote now. And similarly agit-annex get --from webmay be run by someone other than the person who ranaddurl.And
git-annex importfeeddiscovers other urls, but is otherwise equivilant to the user runninggit-annex addurlthemselves on those urls. In one case the user gave the url to a git-annex command, and in the ther case they did not. It does not really make sense for git-annex to distinguish those two cases, but either thing it picks will violate the git documentation.Now, git-annex could choose to diverge from git and always use the config. But bear in mind that extraheader config is asking some very similar questions about another
http.config. Which could be a security hole if it exposes the config to the wrong urls.What might make sense would be for git-annex to support
http.<url>.sslCAInfoandhttp.<url>.sslCAPathonly where git does. So for a git remote url, and not for anything else. I think that would also make sense for the extraheader config.git-annex initremote type=git-lfsdoes setgit.remote.url, so it cannot be distinguished if a git-lfs remote got its url set by the user cloning or adding a git remote or by initremote. In the first 2 cases, matching the url against the git configs seems right; in the last case it's not clear what it should do.This could I suppose be fixed by documenting better that it sets
git.remote.url. So the user knows that they set the config with that command, and won't be surprised that Remote.GitLFS matches the remote url against the git configs.