Re: [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)

The latest maintenance release Git v2.2.1 is now available at the usual places.

This is a security-fix for CVE-2014-9390, which affects users on Windows and Mac OS X but not typical UNIX users. A set of new releases for older maintenance tracks (v1.8.5.6, v1.9.5, v2.0.5, and v2.1.4) are published at the same time and they contain the same fix. Various implementations and ports, including Git for Windows, Git OS X installer, JGit & EGit, libgit2 (and Visual Studio which uses it) have been updated at the same time.

Even though the issue may not affect Linux users, if you are a hosting service whose users may fetch from your service to Windows or Mac OS X machines, you are strongly encouraged to update to protect such users who use existing versions of Git.

The tarballs are found at:

    https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.2.1' tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v2.2.1 Release Notes ========================

Fixes since v2.2 ----------------

 * We used to allow committing a path ".Git/config" with Git that is
   running on a case sensitive filesystem, but an attempt to check out
   such a path with Git that runs on a case insensitive filesystem
   would have clobbered ".git/config", which is definitely not what
   the user would have expected.  Git now prevents you from tracking
   a path with ".Git" (in any case combination) as a path component.

 * On Windows, certain path components that are different from ".git"
   are mapped to ".git", e.g. "git~1/config" is treated as if it were
   ".git/config".  HFS+ has a similar issue, where certain unicode
   codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
   it were ".git/config".  Pathnames with these potential issues are
   rejected on the affected systems.  Git on systems that are not
   affected by this issue (e.g. Linux) can also be configured to
   reject them to ensure cross platform interoperability of the hosted
   projects.

 * "git fsck" notices a tree object that records such a path that can
   be confused with ".git", and with receive.fsckObjects configuration
   set to true, an attempt to "git push" such a tree object will be
   rejected.  Such a path may not be a problem on some filesystems
   but in order to protect those on HFS+ and on case insensitive
   filesystems, this check is enabled on all platforms.

A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.

Also contains typofixes, documentation updates and trivial code clean-ups.

----------------------------------------------------------------

Changes since v2.2.0 are as follows:

Hartmut Henkel (1):
      l10n: de.po: fix typos

Jeff King (8):
      unpack-trees: propagate errors adding entries to the index
      read-tree: add tests for confusing paths like ".." and ".git"
      verify_dotfile(): reject .git case-insensitively
      t1450: refactor ".", "..", and ".git" fsck tests
      fsck: notice .git case-insensitively
      utf8: add is_hfs_dotgit() helper
      read-cache: optionally disallow HFS+ .git variants
      fsck: complain about HFS+ ".git" aliases in trees

Johannes Schindelin (3):
      path: add is_ntfs_dotgit() helper
      read-cache: optionally disallow NTFS .git variants
      fsck: complain about NTFS ".git" aliases in trees

Junio C Hamano (6):
      Start post 2.2 cycle
      Git 1.8.5.6
      Git 1.9.5
      Git 2.0.5
      Git 2.1.4
      Git 2.2.1

Hello. Thank you for the fix.

Would it be more reliable to compare inode of directory in question and ".git"? (there is [*] for windows). So that any unspotted name equivalence is prevented to cause any harm.

*) http://stackoverflow.com/questions/7162164/does-windows-have-inode-numbers-like-linux

Hi Max,

On Fri, 19 Dec 2014, Max Kirillov wrote:

You are welcome.

We were considering this, really. The biggest problem we had with this approach is that the most important aspect of releasing a new version was to let hosting sites protect their users via receive.fsckObjects = true (which all hosting sites should activate anyway) by rejecting the ill-intentioned file names in hand-crafted tree objects.

This turned out to be much more important than the user-facing aspect: many users will not update (in many cases, users will be prevented by administrators from updating their software themselves, even).

Therefore, we really tried very hard to get the checks right without having to write out non-bare repositories on Windows (or for that matter, on MacOSX).

Having said that, I would welcome additional safeguards on the users' side, such as what you suggested; I had written out the code in a mail thread between the Git security squad (in addition to nFileIndexHigh and nFileIndexLow, we need to check dwVolumeSerialNumber, too), maybe you want to take this further?

-- snip -- Untested code snippet to illustrate what I have in mind:

	static int is_git_directory(const char *path) {
		static int initialized;
		static DWORD dwVolumeSerialNumber, nFileSizeHigh, nFileSizeLow;

		HANDLE handle;
		BY_HANDLE_FILE_INFORMATION info;
		int result = 0;

		if (!initialized) {
			handle = CreateFile(get_git_dir(), 0,
				FILE_SHARE_READ, 0, OPEN_EXISTING,
				FILE_ATTRIBUTE_NORMAL);

			if (handle != INVALID_HANDLE_VALUE) {
				if (GetFileInformationByHandle(handle, &info)) {
					dwVolumeSerialNumber =
						info.dwVolumeSerialNumber;
					nFileSizeHigh = info.nFileSizeHigh;
					nFileSizeLow = info.nFileSizeLow;
				}
				CloseHandle(handle);
			}
			initialized = 1;
		}

		handle = CreateFile(path, 0, FILE_SHARE_READ, 0, OPEN_EXISTING,
			FILE_ATTRIBUTE_NORMAL);

		if (handle != INVALID_HANDLE_VALUE) {
			if (GetFileInformationByHandle(handle, &info)) {
				result = dwVolumeSerialNumber ==
					info.dwVolumeSerialNumber &&
					nFileSizeHigh == info.nFileSizeHigh &&
					nFileSizeLow == info.nFileSizeLow;
			}
			CloseHandle(handle);
		}
		return result;
	}

	static inline int is_in_git_directory(const char *path) {
		char *copy = xstrdup(path);
		while (PathRemoveFileSpec(path)) {
			if (is_git_directory(path)) {
				free(copy);
				return 1;
			}
		}
		free(copy);
		return 0;
	}

This *should* be good enough.

I fear that this will have a performance impact that might be alleviated by caching results.

What do you think? -- snap --

Please note that this code has been written inside a mail program and has never seen a compiler.

This function – `is_in_git_directory()` – would be called at the start of `verify_path()`, protected by an `if (protect_ntfs)` guard, and of course we would need to have a POSIX version using inodes, too, because – believe it or not – there are Linux users using Git on NTFS volumes.

The problems I see with this are:

1) it really might affect performance very negatively, as it has to
   perform recursive checks for *all* the paths about to be checked out,

2) we would really need to make sure that the function cannot be called
   *before* initializing the .git/ directory in `git init` and `git clone`,
   and

3) it would not protect submodules' .git/ directories (before we switched
   to writing out .git files redirecting to the super project's .git/
   directory, Git initialized .git/ directories inside the submodules'
   working directories).

Ciao, Johannes