civetweb/civetweb

Error when cloning on Windows with Git 2.24: filename in tree entry contains backslash -- solved in Git 2.25

carlescufi opened this issue · 14 comments

The project triggers an error when cloning on Windows when using Git 2.24 or higher:
filename in tree entry contains backslash: '\'

Workaround

Disable core.protectNTFS:
git config --global core.protectNTFS false

Additional details can be found here:
zephyrproject-rtos/zephyr#21426

I checked the file 这是一个示例文本.html in the commit 4ac467e.
The file name is "this is a sample text" in Chinese characters, but all characters are in the BMP, so we do not even need Surrogates here ... and there is definitely no backslash in the file name. CivetWeb has this file in a test folder, to check if non-ascii URLs work like expected.
The file and this test are perfectly valid.

I have an older version of git on Windows and it works there ... so, it seems to me, this is a recent bug in git (for Windows), not a bug in CivetWeb.

@bel2125 thanks for the reply.
This is not clearly a bug in Git for Windows, since it addresses a vulnerability. See the discussion in this issue for more information.
The issue in the civetweb repository might not be related to the file in commit 4ac467e, but perhaps somewhere else in the repo's history, since this will be checked for all tree objects. There is almost certainly some point in the repo's history where a file with backslashes was added, but we haven't been able to find which exactly.

@bel2125 @mbolivar
could the offending file be the one that was removed by 83dc425?
Edit: I tested this and indeed the issue is the file test/\/a.txt, introduced by 9d3af98 and removed in 83dc425

There are two possible solutions to this problem:

  1. Wait to see if Git changes its behavior and only checks the files in the index, not in all tree objects
  2. Rewrite the history of civetweb to remove any traces of that file (and potentially others)

This test/\/a.txt dates back to 2012, years before CivetWeb was forked from Mongoose.
Today CivetWeb has 586 public forks on GitHub, several private forks on GitHub and probably countless copies in other places (e.g. in Git repositories hosted locally in companies).
I think "rewrite history" is way off the scale.

Do you have a reference to this Git issue?

Do you have a reference to this Git issue?

You already posted it ... git-for-windows/git#2435

I wonder if CivetWeb is the only repository with this kind of issue.

I wonder if CivetWeb is the only repository with this kind of issue.

Not quite, no, though it doesn't seem to be very common:

git-for-windows/git#2435 is probably fixed in Git for Windows 2.25 (fixed in v2.25.0-rc1.windows.1)

#809 seems to be a different issue - it does not use Git for Windows and problem seems to be *.cmd files there.

It's a Git issue, not a CivetWeb issue. Should we keep this issue open until Git for Windows 2.25 is released? Should we add some comment in the README not to use V2.24 with CivetWeb?

Should we keep this issue open until Git for Windows 2.25 is released? Should we add some comment in the README not to use V2.24 with CivetWeb?

IMO, that would be a reasonable way to resolve this.

Do you know what versions of Git for Windows are affected? V2.24 ... what about earlier versions V2.23, V2.22, ...?
Do you know when V2.25 will be available (approximately)?

Do you know what versions of Git for Windows are affected? V2.24 ... what about earlier versions V2.23, V2.22, ...?

I believe it's just 2.24.

Do you know when V2.25 will be available (approximately)?

git-for-windows/git#2435 (comment)

@bel2125 I agree with the proposal. A brief mention that Git 2.24 has an issue with Civetweb on Windows should cover it.

Done:
61a868b

Let's keep this note for a couple of months, ... until we can assume most of the developers updated.

Hey guys. I don't actually use civetweb or really know what it is, but I stumbled upon this thread while researching this same issue. This does appear to be fixed in git 2.25 and you can find notes about it in the 2.25 Release Notes:

 * An earlier update to Git for Windows declared that a tree object is
   invalid if it has a path component with backslash in it, which was
   overly strict, which has been corrected.  The only protection the
   Windows users need is to prevent such path (or any path that their
   filesystem cannot check out) from entering the index.
   (merge 224c7d70fa js/mingw-loosen-overstrict-tree-entry-checks later to maint).

Cheers!

Solved in Git 2.25
A note not to use Git 2.24 will remain in the README for a while.