Re: [PATCH v3 1/5] Documentation: define protected configuration

From: Junio C Hamano <gitster@pobox.com>
Date: May 27, 2022, 23:29 UTC
Message-ID: <xmqqh75a1rmd.fsf@gitster.g>
In-Reply-To: <575676c760d9a2ce4a59d50e93aa0f45d54620ab.1653685761.git.gitgitgadget@gmail.com>

"Glen Choo via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 9 quoted lines

>  safe.directory::
> -	These config entries specify Git-tracked directories that are
> -	considered safe even if they are owned by someone other than the
> -	current user. By default, Git will refuse to even parse a Git
> -	config of a repository owned by someone else, let alone run its
> -	hooks, and this config setting allows users to specify exceptions,
> -	e.g. for intentionally shared repositories (see the `--shared`
> -	option in linkgit:git-init[1]).
> +	'(Protected config only) ' These config entries specify

What's the SP in "only) '" doing?

Show 24 quoted lines

> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index aa2f41f5e70..a669983abd6 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -483,6 +483,24 @@ exclude;;
>  	head ref. If the remote <<def_head,head>> is not an
>  	ancestor to the local head, the push fails.
>  
> +[[def_protected_config]]protected configuration::
> +	Protected configuration is configuration that Git considers more
> +	trustworthy because it is unlikely to be tampered with by an
> +	attacker. For security reasons, some configuration variables are
> +	only respected when they are defined in protected configuration.
> ++
> +Protected configuration includes:
> ++
> +- system-level config, e.g. `/etc/git/config`
> +- global config, e.g. `$XDG_CONFIG_HOME/git/config` and
> +  `$HOME/.gitconfig`
> +Protected configuration excludes:
> ++
> +- repository config, e.g. `$GIT_DIR/config` and
> +  `$GIT_DIR/config.worktree`
> +- the command line option `-c` and its equivalent environment variables

The description is a bit unclear what "protected configuration" refers.

If it is the scopes (as in "git config --show-scope") Git can trust more, in other words, a statement like this

    safe.directory is honored only when it comes from a protected
    configuration.

is what you want to make easier to write by introducing a new phrase, perhaps use the word "scope" for more consistency? E.g.

    Only safe.directory that is defined in a trusted scope is
    honored.

I dunno.

It would make sense to give a rationale behind the seemingly arbitrary choice of what is and what is not "protected". Not necessarily in the glossary, but in the proposed log message of the commit that makes the decision. The rationale must help readers to be able to answer the following questions.

 - The system level is "protected" because?  Is it because we do not
   even try to protect ourselves from those who can write anywhere
   in /etc/ or other system directories?

 - The per-user config is "protected" because?  Is it because our
   primary interest in "protection" is to protect individual users
   from landmines laid in the filesystem by other users, and those
   who can already write into $HOME are not we try to guard against?

 - The per-repo config is not "protected" (i.e. "trusted"), because?
   If we are not honoring a configuration in the repository, why are
   we working in that repository in the first place?

 - The per invocation config is not "protected" (i.e. "trusted"),
   because?  If we cannot trusting our own command line, what
   prevents an attacker from mucking with our command line to say
   "sudo whatever" using the same attack vector?

Thanks.