Hi, 1234dev wrote: > Jeff King wrote: >> It is absolutely not safe to run Git commands from a tarball of an >> untrusted repo. There are many ways to execute arbitrary code specified >> by a config option, and you'd be getting recipients .git/config. >> Likewise for hooks. (By the way, this is an area of active work. If you'd like to help, that's welcome. :) See also https://lore.kernel.org/git/20171002234517.GV19555@xxxxxxxxxxxxxxxxxxxxxxxxx/ and https://lore.kernel.org/git/20191116011125.GG22855@xxxxxxxxxx/.) >> And while we would consider it a bug if you can trigger a memory error >> by reading a corrupted or malicious on-disk file, that's gotten way >> less auditing than the code paths which take in objects from a remote. >> So e.g., I would not be surprised if there are vulnerabilities that >> could cause out-of-bounds reads of a corrupted .git/index. Cc-ing Josh Steadmon in case he has pointers for how to add some fuzz tests to harden this kind of thing. We definitely want to find any vulnerabilities in this area. (In addition to the case of "ask a friendly sysadmin or member of GitHub tech support to debug my broken repo", this also would affect any users collaborating on a repository on a shared filesystem.) [...] > To work around this problem, should we instead host this repo on a > public service? If so which one would you recommend? If you want to use ordinary file transfer mechanisms to share a repository, you can use "git bundle" to create a copy of your Git repo in a form that is meant to be safe and straightforward to pass around. See "git help bundle" for more details. Thanks and hope that helps, Jonathan
