RE: [PATCH 3/3] verify_path: consider dos drive prefix

RE: [PATCH 3/3] verify_path: consider dos drive prefix

[Theo Niessink]

Junio C Hamano wrote:
> Here is what I queued last night. If it looks Ok then I'll merge it down
> to 'next'.

I have run a couple of quick tests, and everything seems OK, except the
following backslashed paths, which are verified OK while they should be
rejected:

foo\.\bar
foo\..\bar

This is caused by verify_dotfile(), which doesn't use is_dir_sep(). So I
propose this patch on verify_dotfile():

diff --git a/read-cache.c b/read-cache.c
index 282c0c1..72be7cd 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -726,11 +726,12 @@ static int verify_dotfile(const char *rest)
 	 * has already been discarded, we now test
 	 * the rest.
 	 */
-	switch (*rest) {
+
 	/* "." is not allowed */
-	case '\0': case '/':
+	if (*rest == '\0' || is_dir_sep(*rest))
 		return 0;
 
+	switch (*rest) {
 	/*
 	 * ".git" followed by  NUL or slash is bad. This
 	 * shares the path end test with the ".." case.
@@ -743,7 +744,7 @@ static int verify_dotfile(const char *rest)
 		rest += 2;
 	/* fallthrough */
 	case '.':
-		if (rest[1] == '\0' || rest[1] == '/')
+		if (rest[1] == '\0' || is_dir_sep(rest[1]))
 			return 0;
 	}
 	return 1;

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Wed, Jun 8, 2011 at 11:55 AM, Theo Niessink <niessink@martinic.com> wrote:
> Junio C Hamano wrote:
>> Here is what I queued last night. If it looks Ok then I'll merge it down
>> to 'next'.
>
> I have run a couple of quick tests, and everything seems OK, except the
> following backslashed paths, which are verified OK while they should be
> rejected:
>
> foo\.\bar
> foo\..\bar
>
> This is caused by verify_dotfile(), which doesn't use is_dir_sep(). So I
> propose this patch on verify_dotfile():
>
> diff --git a/read-cache.c b/read-cache.c
> index 282c0c1..72be7cd 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -726,11 +726,12 @@ static int verify_dotfile(const char *rest)
>         * has already been discarded, we now test
>         * the rest.
>         */
> -       switch (*rest) {
> +
>        /* "." is not allowed */
> -       case '\0': case '/':
> +       if (*rest == '\0' || is_dir_sep(*rest))
>                return 0;
>
> +       switch (*rest) {
>        /*
>         * ".git" followed by  NUL or slash is bad. This
>         * shares the path end test with the ".." case.
> @@ -743,7 +744,7 @@ static int verify_dotfile(const char *rest)
>                rest += 2;
>        /* fallthrough */
>        case '.':
> -               if (rest[1] == '\0' || rest[1] == '/')
> +               if (rest[1] == '\0' || is_dir_sep(rest[1]))
>                        return 0;
>        }
>        return 1;
>
>
>

This looks obviously correct to me. Thanks for spotting the problem.

Would you mind writing up a commit-message and supply a sign-off?

RE: [PATCH 3/3] verify_path: consider dos drive prefix

[Theo Niessink]

Erik Faye-Lund wrote:
> This looks obviously correct to me. Thanks for spotting the problem.
> 
> Would you mind writing up a commit-message and supply a sign-off?

Like this you mean?

-- >8 --
Subject: [PATCH] verify_dotfile(): do not assume '/' is the path seperator

verify_dotfile() currently assumes that the path seperator is '/', but on
Windows it can also be '\\', so use is_dir_sep() instead.
    
Signed-off-by: Theo Niessink <theo@taletn.com>
---
 read-cache.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 282c0c1..72be7cd 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -726,11 +726,12 @@ static int verify_dotfile(const char *rest)
 	 * has already been discarded, we now test
 	 * the rest.
 	 */
-	switch (*rest) {
+
 	/* "." is not allowed */
-	case '\0': case '/':
+	if (*rest == '\0' || is_dir_sep(*rest))
 		return 0;
 
+	switch (*rest) {
 	/*
 	 * ".git" followed by  NUL or slash is bad. This
 	 * shares the path end test with the ".." case.
@@ -743,7 +744,7 @@ static int verify_dotfile(const char *rest)
 		rest += 2;
 	/* fallthrough */
 	case '.':
-		if (rest[1] == '\0' || rest[1] == '/')
+		if (rest[1] == '\0' || is_dir_sep(rest[1]))
 			return 0;
 	}
 	return 1;
-- 
1.7.5.3776.g5dcaf.dirty

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Wed, Jun 8, 2011 at 2:04 PM, Theo Niessink <theo@taletn.com> wrote:
> Erik Faye-Lund wrote:
>> This looks obviously correct to me. Thanks for spotting the problem.
>>
>> Would you mind writing up a commit-message and supply a sign-off?
>
> Like this you mean?

Just like that, indeed!

Junio, what do you think, is this OK? I'd be great if we could have
this applied upstream, and then rebase-merge our branch on top for the
next Git for Windows release.

[PATCH maint 0/3] do not write files outside of work-dir

[Erik Faye-Lund]

Theo Niessink has uncovered a serious sercurity issue in Git for Windows,
where cloning an evil repository can arbitrarily overwrite files outside
the repository. Since many Windows users run as administrators, this can
be used for very nasty purposes.

The first two patches fix "git add" so it reject paths outside of the
repository when specified in the "C:\..."-form on Windows.

Patch 3/3 makes sure we don't try to actually write to these files.

This series applies cleanly to 'maint', and I strongly encourage that
we apply at the very least 3/3 there.

Erik Faye-Lund (1):
  verify_path: consider dos drive prefix

Theo Niessink (2):
  A Windows path starting with a backslash is absolute
  real_path: do not assume '/' is the path seperator

 abspath.c         |    4 ++--
 cache.h           |    2 +-
 compat/mingw.h    |    9 +++++++++
 git-compat-util.h |    4 ++++
 read-cache.c      |    5 ++++-
 5 files changed, 20 insertions(+), 4 deletions(-)

-- 
1.7.5.3.3.g435ff

[PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

If someone manage to create a repo with a 'C:' entry in the
root-tree, files can be written outside of the working-dir. This
opens up a can-of-worms of exploits.

Fix it by explicitly checking for a dos drive prefix when verifying
a paht. While we're at it, make sure that paths beginning with '\' is
considered absolute as well.

Noticed-by: Theo Niessink <theo@taletn.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
 read-cache.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f38471c..68faa51 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -753,11 +753,14 @@ int verify_path(const char *path)
 {
 	char c;
 
+	if (has_dos_drive_prefix(path))
+		return 0;
+
 	goto inside;
 	for (;;) {
 		if (!c)
 			return 1;
-		if (c == '/') {
+		if (is_dir_sep(c)) {
 inside:
 			c = *path++;
 			switch (c) {
-- 
1.7.5.3.3.g435ff

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Johannes Sixt]

Am 27.05.2011 18:00, schrieb Erik Faye-Lund:
> If someone manage to create a repo with a 'C:' entry in the
> root-tree, files can be written outside of the working-dir. This
> opens up a can-of-worms of exploits.
> 
> Fix it by explicitly checking for a dos drive prefix when verifying
> a paht. While we're at it, make sure that paths beginning with '\' is
> considered absolute as well.

I think we do agree that the only way to avoid the security breach is to
check a path before it is used to write a file. In practice, it means to
disallow paths in the top-most level of the index that are two
characters long and are letter-colon.

IMHO, it is pointless to avoid that an evil path enters the repository,
because there are so many and a few more ways to create an evil repository.

> diff --git a/read-cache.c b/read-cache.c
> index f38471c..68faa51 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -753,11 +753,14 @@ int verify_path(const char *path)
>  {
>  	char c;
>  
> +	if (has_dos_drive_prefix(path))
> +		return 0;
> +

Isn't verify_path used to avoid that a bogus path enters the index? (I
don't know, I'm not familiar with this infrastructure.)

>  	goto inside;
>  	for (;;) {
>  		if (!c)
>  			return 1;
> -		if (c == '/') {
> +		if (is_dir_sep(c)) {
>  inside:

And if so, at this point, all backslashes should have been converted to
forward-slashes already. If not, then this would just paper over the
real bug.

>  			c = *path++;
>  			switch (c) {

-- Hannes

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Fri, May 27, 2011 at 8:58 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 27.05.2011 18:00, schrieb Erik Faye-Lund:
>> If someone manage to create a repo with a 'C:' entry in the
>> root-tree, files can be written outside of the working-dir. This
>> opens up a can-of-worms of exploits.
>>
>> Fix it by explicitly checking for a dos drive prefix when verifying
>> a paht. While we're at it, make sure that paths beginning with '\' is
>> considered absolute as well.
>
> I think we do agree that the only way to avoid the security breach is to
> check a path before it is used to write a file. In practice, it means to
> disallow paths in the top-most level of the index that are two
> characters long and are letter-colon.
>
> IMHO, it is pointless to avoid that an evil path enters the repository,
> because there are so many and a few more ways to create an evil repository.
>

Yes, but this patch doesn't prevent that; it prevents an evil path
from entering the index and from being checked out if the index is
evil.

>> diff --git a/read-cache.c b/read-cache.c
>> index f38471c..68faa51 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -753,11 +753,14 @@ int verify_path(const char *path)
>>  {
>>       char c;
>>
>> +     if (has_dos_drive_prefix(path))
>> +             return 0;
>> +
>
> Isn't verify_path used to avoid that a bogus path enters the index? (I
> don't know, I'm not familiar with this infrastructure.)
>

Yes, it's being used to do that. But it's also being used when reading
the index into memory, which is "the good stuf" for our purposes.

This is the same guard which makes Git on Linux bard on an index
containing paths like "/tmp/foo"

>>       goto inside;
>>       for (;;) {
>>               if (!c)
>>                       return 1;
>> -             if (c == '/') {
>> +             if (is_dir_sep(c)) {
>>  inside:
>
> And if so, at this point, all backslashes should have been converted to
> forward-slashes already. If not, then this would just paper over the
> real bug.

SHOULD, yes. But we could have an evil tree/index which doesn't, and
this if intended to make sure we reject such paths.

So I don't see how this is papering over the bug; this IS the bug (as
far as I can tell).

But I think I might have been a bit too care-less; I didn't fix the
switch-case to check for multiple backslashes on Windows. It's not
immediately obvious if this is needed or not, but I don't think it can
cause harm; we should never have created an index like that anyway.

So something like this on top, perhaps?


diff --git a/read-cache.c b/read-cache.c
index 68faa51..9367349 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -763,15 +763,11 @@ int verify_path(const char *path)
 		if (is_dir_sep(c)) {
 inside:
 			c = *path++;
-			switch (c) {
-			default:
-				continue;
-			case '/': case '\0':
-				break;
-			case '.':
+			if (c == '.') {
 				if (verify_dotfile(path))
 					continue;
-			}
+			} else if (!is_dir_sep(c) && c != '\0')
+				continue;
 			return 0;
 		}
 		c = *path++;

RE: [PATCH 3/3] verify_path: consider dos drive prefix

[Theo Niessink]

Erik Faye-Lund wrote:
> But I think I might have been a bit too care-less; I didn't fix the
> switch-case to check for multiple backslashes on Windows. It's not
> immediately obvious if this is needed or not, but I don't think it can
> cause harm; we should never have created an index like that anyway.
> 
> So something like this on top, perhaps?

Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
continue? It will check for '\0' and is_dir_sep(c) again, but you already
know that both ifs will be false. So you could just as easy jump straight to
c = *path++, which IMHO also makes the code easier to follow:

diff --git a/read-cache.c b/read-cache.c
index 68faa51..089cd3e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -763,17 +763,15 @@ int verify_path(const char *path)
 		if (is_dir_sep(c)) {
 inside:
 			c = *path++;
-			switch (c) {
-			default:
-				continue;
-			case '/': case '\0':
-				break;
-			case '.':
+			if (c == '.') {
+				
 				if (verify_dotfile(path))
 					continue;
-			}
+			} else if (!is_dir_sep(c) && c != '\0')
+				goto next;
 			return 0;
 		}
+next:
 		c = *path++;
 	}
 }

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Mon, May 30, 2011 at 12:58 PM, Theo Niessink <theo@taletn.com> wrote:
> Erik Faye-Lund wrote:
>> But I think I might have been a bit too care-less; I didn't fix the
>> switch-case to check for multiple backslashes on Windows. It's not
>> immediately obvious if this is needed or not, but I don't think it can
>> cause harm; we should never have created an index like that anyway.
>>
>> So something like this on top, perhaps?
>
> Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
> continue? It will check for '\0' and is_dir_sep(c) again, but you already
> know that both ifs will be false. So you could just as easy jump straight to
> c = *path++, which IMHO also makes the code easier to follow:

Very good point, thanks for noticing. I just rewrote the logic from
switch/case to if/else, but with the rewrite these redundant compares
became more obvious. I think your version is better, indeed.

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Junio C Hamano]

Erik Faye-Lund <kusmabite@gmail.com> writes:

>> Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
>> continue? It will check for '\0' and is_dir_sep(c) again, but you already
>> know that both ifs will be false. So you could just as easy jump straight to
>> c = *path++, which IMHO also makes the code easier to follow:
>
> Very good point, thanks for noticing. I just rewrote the logic from
> switch/case to if/else, but with the rewrite these redundant compares
> became more obvious. I think your version is better, indeed.

Let's not add an unnecessary goto while at it.  How about this on top
instead?

 read-cache.c |   13 +++----------
 1 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 31cf0b5..3593291 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -784,16 +784,9 @@ int verify_path(const char *path)
 		if (is_dir_sep(c)) {
 inside:
 			c = *path++;
-			switch (c) {
-			default:
-				continue;
-			case '/': case '\0':
-				break;
-			case '.':
-				if (verify_dotfile(path))
-					continue;
-			}
-			return 0;
+			if ((c == '.' && !verify_dotfile(path)) ||
+			    is_dir_sep(c) || c == '\0')
+				return 0;
 		}
 		c = *path++;
 	}

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Tue, Jun 7, 2011 at 5:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>>> Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
>>> continue? It will check for '\0' and is_dir_sep(c) again, but you already
>>> know that both ifs will be false. So you could just as easy jump straight to
>>> c = *path++, which IMHO also makes the code easier to follow:
>>
>> Very good point, thanks for noticing. I just rewrote the logic from
>> switch/case to if/else, but with the rewrite these redundant compares
>> became more obvious. I think your version is better, indeed.
>
> Let's not add an unnecessary goto while at it.  How about this on top
> instead?
>
>  read-cache.c |   13 +++----------
>  1 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 31cf0b5..3593291 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -784,16 +784,9 @@ int verify_path(const char *path)
>                if (is_dir_sep(c)) {
>  inside:
>                        c = *path++;
> -                       switch (c) {
> -                       default:
> -                               continue;
> -                       case '/': case '\0':
> -                               break;
> -                       case '.':
> -                               if (verify_dotfile(path))
> -                                       continue;
> -                       }
> -                       return 0;
> +                       if ((c == '.' && !verify_dotfile(path)) ||
> +                           is_dir_sep(c) || c == '\0')
> +                               return 0;
>                }
>                c = *path++;
>        }

This change the "c == '.' && verify_dotfile(path)"-case to eat the '.'
character without testing it against is_dir_sep, which is exactly what
we want. The other cases return 0, as they used to. Good.

Indeed, this is a cleaner approach. Thanks!

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Tue, Jun 7, 2011 at 12:07 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Tue, Jun 7, 2011 at 5:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>
>>>> Nitpick: If you already know that c != '\0' and !is_dir_sep(c), then why do
>>>> continue? It will check for '\0' and is_dir_sep(c) again, but you already
>>>> know that both ifs will be false. So you could just as easy jump straight to
>>>> c = *path++, which IMHO also makes the code easier to follow:
>>>
>>> Very good point, thanks for noticing. I just rewrote the logic from
>>> switch/case to if/else, but with the rewrite these redundant compares
>>> became more obvious. I think your version is better, indeed.
>>
>> Let's not add an unnecessary goto while at it.  How about this on top
>> instead?
>>
>>  read-cache.c |   13 +++----------
>>  1 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/read-cache.c b/read-cache.c
>> index 31cf0b5..3593291 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -784,16 +784,9 @@ int verify_path(const char *path)
>>                if (is_dir_sep(c)) {
>>  inside:
>>                        c = *path++;
>> -                       switch (c) {
>> -                       default:
>> -                               continue;
>> -                       case '/': case '\0':
>> -                               break;
>> -                       case '.':
>> -                               if (verify_dotfile(path))
>> -                                       continue;
>> -                       }
>> -                       return 0;
>> +                       if ((c == '.' && !verify_dotfile(path)) ||
>> +                           is_dir_sep(c) || c == '\0')
>> +                               return 0;
>>                }
>>                c = *path++;
>>        }
>
> This change the "c == '.' && verify_dotfile(path)"-case to eat the '.'
> character without testing it against is_dir_sep, which is exactly what
> we want. The other cases return 0, as they used to. Good.
>
> Indeed, this is a cleaner approach. Thanks!
>

I forgot to ask; do you want me to resend? I would imagine the commit
message should be updated to reflect this change as well...

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Junio C Hamano]

Erik Faye-Lund <kusmabite@gmail.com> writes:

> I forgot to ask; do you want me to resend? I would imagine the commit
> message should be updated to reflect this change as well...

Here is what I queued last night. If it looks Ok then I'll merge it down
to 'next'.

-- >8 --
Subject: [PATCH] verify_path(): simplify check at the directory boundary

We simply want to say "At a directory boundary, be careful with a name
that begins with a dot, forbid a name that ends with the boundary
character or has duplicated bounadry characters".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 read-cache.c |   13 +++----------
 1 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 31cf0b5..3593291 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -784,16 +784,9 @@ int verify_path(const char *path)
 		if (is_dir_sep(c)) {
 inside:
 			c = *path++;
-			switch (c) {
-			default:
-				continue;
-			case '/': case '\0':
-				break;
-			case '.':
-				if (verify_dotfile(path))
-					continue;
-			}
-			return 0;
+			if ((c == '.' && !verify_dotfile(path)) ||
+			    is_dir_sep(c) || c == '\0')
+				return 0;
 		}
 		c = *path++;
 	}
-- 
1.7.6.rc0.129.gbe6ef

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Erik Faye-Lund]

On Tue, Jun 7, 2011 at 9:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> I forgot to ask; do you want me to resend? I would imagine the commit
>> message should be updated to reflect this change as well...
>
> Here is what I queued last night. If it looks Ok then I'll merge it down
> to 'next'.
>
> -- >8 --
> Subject: [PATCH] verify_path(): simplify check at the directory boundary
>
> We simply want to say "At a directory boundary, be careful with a name
> that begins with a dot, forbid a name that ends with the boundary
> character or has duplicated bounadry characters".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  read-cache.c |   13 +++----------
>  1 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 31cf0b5..3593291 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -784,16 +784,9 @@ int verify_path(const char *path)
>                if (is_dir_sep(c)) {
>  inside:
>                        c = *path++;
> -                       switch (c) {
> -                       default:
> -                               continue;
> -                       case '/': case '\0':
> -                               break;
> -                       case '.':
> -                               if (verify_dotfile(path))
> -                                       continue;
> -                       }
> -                       return 0;
> +                       if ((c == '.' && !verify_dotfile(path)) ||
> +                           is_dir_sep(c) || c == '\0')
> +                               return 0;
>                }
>                c = *path++;
>        }

Looks good to me, thanks for following up on it :)

RE: [PATCH 3/3] verify_path: consider dos drive prefix

[Theo Niessink]

Junio C Hamano wrote: 
> Let's not add an unnecessary goto while at it.  How about this on top
> instead?

Yeah, that is much cleaner indeed.

- Theo

Re: [PATCH 3/3] verify_path: consider dos drive prefix

[Johannes Sixt]

Am 30.05.2011 11:32, schrieb Erik Faye-Lund:
> On Fri, May 27, 2011 at 8:58 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Am 27.05.2011 18:00, schrieb Erik Faye-Lund:
>>> If someone manage to create a repo with a 'C:' entry in the
>>> root-tree, files can be written outside of the working-dir. This
>>> opens up a can-of-worms of exploits.
>>>
>>> Fix it by explicitly checking for a dos drive prefix when verifying
>>> a paht. While we're at it, make sure that paths beginning with '\' is
>>> considered absolute as well.
>>
>> I think we do agree that the only way to avoid the security breach is to
>> check a path before it is used to write a file. In practice, it means to
>> disallow paths in the top-most level of the index that are two
>> characters long and are letter-colon.
>>
>> IMHO, it is pointless to avoid that an evil path enters the repository,
>> because there are so many and a few more ways to create an evil repository.
>>
> 
> Yes, but this patch doesn't prevent that; it prevents an evil path
> from entering the index and from being checked out if the index is
> evil.
> 
>>> diff --git a/read-cache.c b/read-cache.c
>>> index f38471c..68faa51 100644
>>> --- a/read-cache.c
>>> +++ b/read-cache.c
>>> @@ -753,11 +753,14 @@ int verify_path(const char *path)
>>>  {
>>>       char c;
>>>
>>> +     if (has_dos_drive_prefix(path))
>>> +             return 0;
>>> +
>>
>> Isn't verify_path used to avoid that a bogus path enters the index? (I
>> don't know, I'm not familiar with this infrastructure.)
>>
> 
> Yes, it's being used to do that. But it's also being used when reading
> the index into memory, which is "the good stuf" for our purposes.

OK, I agree with the changes proposed in this patch. git reset and git
checkout go through this function via unpack_trees(). Are there other
ways to write a file, e.g., in merge-recursive?

-- Hannes