From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Paul Smith <paul@mad-scientist.net>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: RUNTIME_PREFIX references in gitconfig variable paths
Date: Tue, 2 Oct 2018 16:28:26 +0200 (DST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1810021611040.2034@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <55733da67095123ced63095aa554970053bef321.camel@mad-scientist.net>
Hi Paul,
[late reply, I know, sorry about that!]
On Wed, 4 Jul 2018, Paul Smith wrote:
> On Wed, 2018-07-04 at 13:26 +0200, Johannes Schindelin wrote:
> > On Wed, 4 Jul 2018, Paul Smith wrote:
> >
> > > One thing I wanted to do was provide a default ca-bundle.crt file
> > > along with my local build of Git. I need my installation to be
> > > relocatable and I'm using RUNTIME_PREFIX with Git 2.18.0 (on
> > > GNU/Linux).
> >
> > Understandable. We do this all the time in Git for Windows. Our
> > config entry has this form:
> >
> > [http]
> > sslCAinfo = /ssl/certs/ca-bundle.crt
> >
> > and in the RUNTIME_PREFIX mode, this will be made relative to the
> > runtime prefix. It is my understanding that bf9acba (http: treat
> > config options sslCAPath and sslCAInfo as paths, 2015-11-23) makes
> > this work.
>
> Hm. Unless I'm missing something this doesn't happen (and indeed, it
> does not work for me; with:
>
> [http]
> sslcainfo = /etc/ca-bundle.crt
>
> I get:
>
> fatal: unable to access 'https://github.com/myrepo.git/': error
> setting certificate verify locations:
> CAfile: /etc/ca-bundle.crt
> CApath: none
>
> although it works if I use a fully-qualified pathname, and using strace
> I find the process never attempted to access any other path for ca-
> bundle.crt).
>
> In http.c we see how this path is treated in http_options():
>
> if (!strcmp("http.sslcainfo", var))
> return git_config_pathname(&ssl_cainfo, var, value);
>
> I can't tell exactly how this function is invoked, but the result
> (ssl_cainfo) is used here without further modification:
>
> curl_easy_setopt(result, CURLOPT_CAINFO, ssl_cainfo);
>
> In config.c we find get_config_pathname() which does this:
>
> *dest = expand_user_path(value, 0);
>
> In path.c we find expand_user_path() which does this:
>
> if (path == NULL)
> goto return_null;
> if (path[0] == '~') {
> ...
> }
> strbuf_addstr(&user_path, to_copy);
> return strbuf_detach(&user_path, NULL);
>
> I don't see any reference to system_prefix(), system_path(), etc. which
> would be needed to RUNTIME_PREFIX-ize things.
I finally got around to dig into this, and found out what is
happening: in https://github.com/git/git/blob/v2.19.0/http.c#L295-L296,
the http.sslcainfo setting is handled by calling git_config_pathname(),
which in turn calls expand_user_path() to handle special cases
(https://github.com/git/git/blob/v2.19.0/config.c#L1067-L1075). And it
is this function which has a specific, special handling on Windows
(which, like so many other changes that are waiting patiently for the
slow upstreaming process, has not made it into any *Git* version yet),
see https://github.com/git-for-windows/git/commit/434b76522de1:
@@ -709,6 +710,10 @@ char *expand_user_path(const char *path, int real_home)
if (path == NULL)
goto return_null;
+#ifdef __MINGW32__
+ if (path[0] == '/')
+ return system_path(path + 1);
+#endif
if (path[0] == '~') {
const char *first_slash = strchrnul(path, '/');
const char *username = path + 1;
This explains why it works on Windows, but not elsewhere...
Now, I could imagine that this special handling makes a ton of sense not
for *Git for Windows*, but rather for RUNTIME_PREFIX.
So maybe we should replace that `__MINGW32__` condition by
`RUNTIME_PREFIX`? What do you think?
Ciao,
Johannes
prev parent reply other threads:[~2018-10-02 14:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 6:08 RUNTIME_PREFIX references in gitconfig variable paths Paul Smith
2018-07-04 11:26 ` Johannes Schindelin
2018-07-04 13:56 ` Paul Smith
2018-10-02 14:28 ` Johannes Schindelin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1810021611040.2034@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=paul@mad-scientist.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).