René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Effect of refreshing with a relative path is not obvious","articleBody":"When `git.refresh` or `git.cmd.Git.refresh` (which `git.refresh` calls) is passed a relative path as an explicit `path` argument, it is taken relative to the current working directory of the process GitPython is running in at the time the refresh occurs. However, if instead one of those `refresh` functions is called with no argument and the value of the [`GIT_PYTHON_GIT_EXECUTABLE`](https://github.com/gitpython-developers/GitPython/blob/afa575454f85b34800460881cc9c3cd7fe78c8e3/git/cmd.py#L352) environment variable is a relative path, that value is *not* resolved, but is instead looked up every time it is run. ([The default of `git`](https://github.com/gitpython-developers/GitPython/blob/afa575454f85b34800460881cc9c3cd7fe78c8e3/git/cmd.py#L327-L328) is likewise not resolved.)\r\n\r\nhttps://github.com/gitpython-developers/GitPython/blob/afa575454f85b34800460881cc9c3cd7fe78c8e3/git/cmd.py#L365-L370\r\n\r\nThis appears intentional, and in 8dc8eb9 (#1815) I added tests that assert this behavior. **But this should also be clarified for users**, by documenting it explicitly in the docstring of at least one of the `refresh` functions. I am unsure how best to do this, because ideally the difference should be *explained*, and I don't know if there is any good reason for the two cases to work differently, other than avoiding a breaking change within the same major version of the library.\r\n\r\nIf this is only for compatibility, then it might make sense to have `git.refresh` and `git.cmd.Git.refresh` accept a second optional `resolve` argument to indicate if the first argument is supposed to be eagerly resolved, and issue a `DeprecationWarning` when the `resolve` argument is not passed (i.e., one-argument `git.refresh` calls would be deprecated). This would not substitute for adding an explanation to the docstring.\r\n\r\n#### Security implications\r\n\r\nA user who is confused about this behavior may write code like `git.refresh(\"git\")`, perhaps with the intention of undoing the effect of a previous refresh. If this is done when the current working directory is the working tree of an untrusted repository that contains a malicious `git` executable (or a malicious executable otherwise named the same as the command passed to `refresh`), then GitPython will use that command as `git`, which would be a situation like CVE-2023-40590 or CVE-2024-22190.\r\n\r\nHowever, I am inclined to consider improving how this is documented to be a security enhancement, but not a fix for an existing security vulnerability in GitPython. I think this is not really a vulnerability in GitPython for three reasons. In decreasing order of significance:\r\n\r\n- Such code would typically be identified readily, because a `git` or other such executable inside a repository would not ordinarily occur in testing or normal usage, and an unexpected `GitCommandNotFound` would be raised and observed. In particular, for the typical case of calling `git.refresh` early on, such a mistake would be identified immediately. This differs from those vulnerabilities, where the current directory was searched but then the expected places were searched, and also differs in that this is about a small likelihood of software that uses GitPython introducing its own vulnerability, rather than GitPython itself having inherently vulnerable behavior.\r\n- The behavior of GitPython need not change to fix this, since it is mainly a matter of documentation.\r\n- Searching for uses of `git.refresh` suggests this is not often used at all, and didn't turn up any incorrect uses of relative paths (though this does not guarantee there are no such incorrect uses).\r\n\r\n#### Integration considerations\r\n\r\nWith #1791, the case for documenting this inconsistency becomes stronger, because that will add another refresh-related function, `refresh_bash`, which never resolves the path. Unlike `git`, GitPython often does not need `bash` or does not need it until a hook is needed to run on Windows, so it is more likely that a wrong call to `refresh_bash` would go undetected. Therefore, I very much agree with the decision there not to resolve the path, on security grounds:\r\n\r\nhttps://github.com/gitpython-developers/GitPython/blob/8200ad10463d6df34e9b21c977e0d9092b908611/git/cmd.py#L439-L446\r\n\r\nBecause after #1791 this will be a behavioral difference between the `refresh` functions and `refresh_bash`, this will be a further reason to document the subtlety.\r\n\r\nThis could possibly be included in the docstring modifications there, which would avoid a conflict, but I am somewhat inclined not to request unnecessary enhancements there.","author":{"url":"https://github.com/EliahKagan","@type":"Person","name":"EliahKagan"},"datePublished":"2024-02-19T05:19:59.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/1831/GitPython/issues/1831"}