Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> 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. >> 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 ;-) > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html