Re: Files with colons under Cygwin

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Oct 7, 2008, 00:53 UTC
Message-ID: <20081007005327.GT21650@dpotapov.dyndns.org>
In-Reply-To: <48E9B634.6040909@viscovery.net>

On Mon, Oct 06, 2008 at 08:54:44AM +0200, Johannes Sixt wrote:

> 
> IIUC, verify_path() checks paths that were found in the database or the
> index.

It also checks paths that was given to git add and other commands to prevent an invalid path to enter to the index. If I am not mistaken, if invalid path has entered in the index then it will be committed to the database without any further checks.

> As such, it checks for the integrity of the database. And paths
> with backslashes or colons certainly do not violate the database integrity.

No, it has nothing to do with the database. You can run git fsck --full on a repository that contains '..' or '.' or '.git', and there will be no error. Having those names does not violate the database integrity, as the database is concerned all names are just bytes separated by '/', so having name '.' is not a problem for it. However, names '.' and '..' have special meaning for the filesystem, and paths starting with .git/ have special meaning for Git repository. If you work in a bare repo then those names are not a problem, but once you have a working tree, you want make sure that there is nothing wrong with it.

Show 10 quoted lines

> 
> More precisely, the exchange of path names between the index and tree
> objects (both directions) should not do this new check, nor if a path is
> added to the index. The check is only meaningful[*] when a path is read
> from the index or a tree object and "applied" to the working directory.
> Unfortunately, I think there are lots of places where this happens.
> 
> [*] I say "meaningful" and not "necessary" because the situation is just
> like when you grab some random SoftwarePackage.tar.gz, and run ./configure
> without looking first what it is going to do.

When I grab any tar, I can look at its context without myself of any risk that some files can be overwritten on my file system. And when I want to look at some remote git repository, I usually do:

   git clone URL

If it can overwrite some files behind my back, it is security a hole.

BTW, it was the reason why the idea of allowing .gitconfig to be stored in git repository (similar to .gitignore) was stroke down about a year ago though it could help some clueless users...

On Linux (or other sane file systems), we have all required checks to prevent that from happening, and they are places in verify_path, which prevents malicious names entering into the index and thus to the file system too. So, we should do all required checks on Windows too.

Now, I've realized that my checks were not sufficient (due to Windows being case-insensitive), so I will add more checks and resend this patch later.

Dmitry