Re: [RFC/PATCH 1/2] config: Add safe-include directive
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 6, 2014, 17:58 UTC
- Message-ID
- <xmqq7g0djd0z.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <878uktwnqs.fsf@rasmusvillemoes.dk>
Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:
Show 7 quoted lines
> Junio C Hamano <gitster@pobox.com> wrote: > >> (by the way, we do not do dashes in names for configuration by >> convention) > > OK. Actually, I now think I'd prefer a subsection [include "safe"], but > I don't have any strong preferences regarding the names.
I think Peff mentioned something about having the second level between include and path, so I'll defer it to him.
Show 11 quoted lines
>> That syntax _could_ be just a relative path (e.g. project.gitconfig names >> the file with that name at the top-level of the working tree), and if we are >> to do so, we should forbid any relative path that escapes from the working >> tree (e.g. ../project.gitconfig is forbidden, but down/down/../../.gitconfig >> could be OK as it is the same as .gitconfig). For that matter, anything with >> /./ and /../ in it can safely be forbidden without losing functionality. > > I agree that it would be most useful to interpret relative paths as > being relative to the working tree. I'm not sure what would be gained by > checking for ./ and ../ components, a symlink could easily be used to > circumvent that.
If the "limit to the the working tree" is the reason to suggest a relative path to be taken as relative to the working tree, which my suggestion clearly was, the reader should be intelligent enough to infer that an implementation working in that mode should make sure symlinks and any other means do not step outside it.
And as you noticed that, you apparently are ;-)
Show 6 quoted lines
> One might (ab)use the feature to only use some settings from a global > file, e.g. > > [include "safe"] > whitelist = !foo.* > path = ~/extra.gitconfig
You do not have to write something you do not want to use in your own ~/extra.gitconfig that is under your $HOME/, so I'd prefer to explicitly forbidding such a use case at least in the beginning.