Hi Chris, answers inline. On Mon, 5 Sep 2022, Christoph Anton Mitterer wrote: > Is it known whether this will automatically prevent the issue also for > any 3rd party modules for git? As long as they use the core Git CLI at a new-enough version: yes. But libgit2 and JGit, two separate Git implementations that are in wide use, too, probably do not have support for this. In other words, users of libgit2 & JGit will likely be unaffected by setting `safe.bareRepository` and sill still need to take manual precautions. If you are using applications based on those projects, you might be interested in porting support for `safe.bareRepository` to those projects and contribute the enhancement. > I mean is special action needed by them to consider the option? Or is > it likely that there are some which manually discover the git config > and could thereby still suffer from the vulnerability. > > > I assume the same wouldn't be possible for non-bare embedded repos? I > tried to try this, but when git add(ing) such repo, it already warns > that the embedded (non-bare) repo would not be included in clones. Yes, indeed, `.git` entries in Git's tree objects are forbidden. Ciao, Johannes > On Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote: > > Note: The default will still be at `safe.bareRepository = all`. > > That seems like a not so secure default, given that probably only few > people will ever encounter embedded bare repos. > > OTOH, the attack surface seems rather big, if one just needs to clone > some arbitrary repo where one wants to look at some code, and is then > in principle already fully vulnerable?! > > > Thanks, > Chris. >
