RUNTIME_PREFIX references in gitconfig variable paths

RUNTIME_PREFIX references in gitconfig variable paths

[Paul Smith]

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).

I can provide a system gitconfig file with a setting for http.sslCAInfo
but the problem is I can't create a relocatable path here so I don't
know how to set it:

  $ cat $prefix/etc/gitconfig
  [http]
      sslCAInfo = <prefix>/etc/ca-bundle.crt

What do I use for <prefix> above since I want it to be relocatable? 
Basically I want this to be in the same directory as the relocatable
sysconfdir (I don't actually care much but that seems like a good
place).

Is there some way to create a reference to a path relative to the
installation directory?

For example "~" is accepted as the users $HOME path; is there some
syntax which refers to the Git installation directory?

If not this seems like something that would be very useful.


I can use a wrapper script and set GIT_SSL_CAINFO, but that will also
override any user's setting of http.sslCAInfo in their local gitconfig
which I don't really want.

Re: RUNTIME_PREFIX references in gitconfig variable paths

[Johannes Schindelin]

Hi Paul,

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.

> I can provide a system gitconfig file with a setting for http.sslCAInfo
> but the problem is I can't create a relocatable path here so I don't
> know how to set it:
> 
>   $ cat $prefix/etc/gitconfig
>   [http]
>       sslCAInfo = <prefix>/etc/ca-bundle.crt
> 
> What do I use for <prefix> above since I want it to be relocatable? 
> Basically I want this to be in the same directory as the relocatable
> sysconfdir (I don't actually care much but that seems like a good
> place).
> 
> Is there some way to create a reference to a path relative to the
> installation directory?
> 
> For example "~" is accepted as the users $HOME path; is there some
> syntax which refers to the Git installation directory?
> 
> If not this seems like something that would be very useful.
> 
> 
> I can use a wrapper script and set GIT_SSL_CAINFO, but that will also
> override any user's setting of http.sslCAInfo in their local gitconfig
> which I don't really want.

I think if you simply delete `<prefix>`, it will start working.

Ciao,
Johannes

Re: RUNTIME_PREFIX references in gitconfig variable paths

[Paul Smith]

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.

Re: RUNTIME_PREFIX references in gitconfig variable paths

[Johannes Schindelin]

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