Junio C Hamano <gits...@pobox.com> writes:

> LE Manh Cuong <cuong.manhle...@gmail.com> writes:
>
>> It's not only people shooting their foot, but also from malicious user.
>> Given that `curl url | sudo sh/bash` is often found in many instructions,
>> an end user may not be noticed about the environment variable injection
>> from their side.
>>
>> IMHO, it's better if  git can protect the end users in this situation.
>
> Huh?  For those who run `curl url | sudo sh`, I do not think the
> incoming script setting and exporting LV to an arbitrary value and
> runing Git is not the top thing they need worry about.
>
> While I think enclosing the string in dq is an improvement (as I
> said already), I still do think your use of the v-word is making a
> mountain out of an anthill.

I failed to say why I found the dq is an improvement, but that
should be in the log message of this commit.  Off the top of my
head, something like:

        We often make sure an environment variable is set to
        something, either set by the user (in which case we do not
        molest it) or set it to our default value (otherwise), with

                : ${VAR=default value}

        i.e. running the no-op command ":" with ${VAR} as its
        parameters (or the default value we supply), relying on that
        ":" is a no-op.

        This pattern, even though it is no-op from correctness point
        of view, still can be expensive if the existing value in VAR
        has shell glob (because they will be expanded against
        filesystem entities) and IFS whitespaces (because the value
        need to be split into multiple parameters).  Our invocation
        of ":" command does not care if the parameter given to it is
        after the value in VAR goes through these processing.

        Enclosing the whole thing in double-quote, i.e.

                : "${VAR=default value}"

        avoids paying the unnecessary cost, so let's do so.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to