Hi,
On Thu, 8 Nov 2018, Junio C Hamano wrote:
> I am tempted to say "//<token>/<the remainder>" might also be such a
> way, even in the POSIX world, but am not brave enough to do so, as I
> suspect that may have a fallout in the Windows world X-<.
It does. //server/share is the way we refer to UNC paths (AKA network
drives).
> An earlier suggestion by Duy in [*1*] to pretend as if we take
> $VARIABLE and define special variables might be a better direction.
My only qualm with this is that `$VARIABLE` is a perfectly allowed part of
a path. That is, you *could* create a directory called `$VARIABLE` and
reference that, and then the expand_user_path() function (or whatever name
we will give it) would always expand this, with no way to switch it off.
Granted, this is a highly unlikely scenario, but I would feel a bit more
comfortable with something like
<RUNTIME_PREFIX>/ssl/certs/ca-bundle.crt
Of course, `<RUNTIME_PREFIX>` is *also* a perfectly valid directory name,
but I would argue that it is even less likely to exist than
`$RUNTIME_PREFIX` because the user would have to escape *two* characters
rather than one.
> Are there security implications if we started allowing references to
> environment varibables in strings we pass expand_user_path()?
Probably. But then, the runtime prefix is not even available as
environment variable...
Ciao,
Dscho
> If we cannot convince ourselves that it is safe to allow access to any
> and all environment variables, then we probably can start by specific
> "pseudo variables" under our control, like GIT_EXEC_PATH and
> GIT_INSTALL_ROOT, that do not even have to be tied to environment
> variables, perhaps with further restriction to allow it only at the
> beginning of the string, or something like that, if necessary.
>
> [References]
>
> *1* <cacsjy8dmyu_kn4yytu_pqdpppxo8wlcuuzq-fjwnyja0ntb...@mail.gmail.com>
>
