Re: [PATCH] Teach "git add" and friends to be paranoid

From: Thomas Rast <trast@student.ethz.ch>
Date: Feb 18, 2010, 10:14 UTC
Message-ID: <201002181114.19984.trast@student.ethz.ch>
In-Reply-To: <7vljer1gyg.fsf_-_@alter.siamese.dyndns.org>

On Thursday 18 February 2010 02:16:23 Junio C Hamano wrote:

Show 8 quoted lines

> When creating a loose object, we normally mmap(2) the entire file, and
> hash and then compress to write it out in two separate steps for
> efficiency.
> 
> This is perfectly good for the intended use of git---nobody is supposed to
> be insane enough to expect that it won't break anything to muck with the
> contents of a file after telling git to index it and before getting the
> control back from git.

This makes it sound as if the user is to blame, but IMHO we're just not checking the input well enough. The user should never be able to corrupt the repository (without git noticing!) just by running a git command and manipulating the worktree in parallel. The file data at any given time is just user input, and you also cannot (I hope; otherwise let's fix it!) corrupt the repository merely by typoing some command arguments.

(Mucking around in .git is an entirely different matter, but that is off limits.)

> This teaches the index_mem() codepath to be paranoid and hash and compress
> the data after reading it in core.  The contents hashed may not match the
> contents of the file in an insane use case, but at least this way the
> result will be internally consistent.

Doesn't that trigger on windows, where xmmap() already makes a copy?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch