On 5/27/2022 7:29 PM, Junio C Hamano wrote: > "Glen Choo via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: >> +[[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? I think the answers to these two questions is "yes", so they can be turned into an affirmative sentence: We do not event try to protect ourselves from those who can write anywhere... > - 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? This requires an example: Some workflows use repositories stored in shared directories, which are writable by multiple unprivileged users. > - 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? With this argument, I agree that -c config can be considered protected. At the very least, it is visible to the user when they are running a command. This would unify our expectations with uploadPack.packObjectsHook, too. Thanks, -Stolee
