{"thread":{"id":"38199","subject":"Re: [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)","startedAt":"2014-12-18T21:11:19Z","lastAt":"2014-12-19T09:18:16Z","messageCount":3,"participants":["Max Kirillov","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"299213","messageId":"xmqq61d87jew.fsf@gitster.dls.corp.google.com","threadId":"38199","inReplyTo":null,"subject":"[ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-18T21:11:19Z","receivedAt":"2014-12-18T21:11:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest maintenance release Git v2.2.1 is now available at\nthe usual places.\n\nThis is a security-fix for CVE-2014-9390, which affects users on\nWindows and Mac OS X but not typical UNIX users.  A set of new\nreleases for older maintenance tracks (v1.8.5.6, v1.9.5, v2.0.5, and\nv2.1.4) are published at the same time and they contain the same fix.\nVarious implementations and ports, including Git for Windows, Git OS\nX installer, JGit & EGit, libgit2 (and Visual Studio which uses it)\nhave been updated at the same time.\n\nEven though the issue may not affect Linux users, if you are a\nhosting service whose users may fetch from your service to Windows\nor Mac OS X machines, you are strongly encouraged to update to\nprotect such users who use existing versions of Git.\n\nThe tarballs are found at:\n\n    https://www.kernel.org/pub/software/scm/git/\n\nThe following public repositories all have a copy of the 'v2.2.1'\ntag and the 'maint' branch that the tag points at:\n\n  url = https://kernel.googlesource.com/pub/scm/git/git\n  url = git://repo.or.cz/alt-git.git\n  url = https://code.google.com/p/git-core/\n  url = git://git.sourceforge.jp/gitroot/git-core/git.git\n  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n  url = https://github.com/gitster/git\n\nGit v2.2.1 Release Notes\n========================\n\nFixes since v2.2\n----------------\n\n * We used to allow committing a path \".Git/config\" with Git that is\n   running on a case sensitive filesystem, but an attempt to check out\n   such a path with Git that runs on a case insensitive filesystem\n   would have clobbered \".git/config\", which is definitely not what\n   the user would have expected.  Git now prevents you from tracking\n   a path with \".Git\" (in any case combination) as a path component.\n\n * On Windows, certain path components that are different from \".git\"\n   are mapped to \".git\", e.g. \"git~1/config\" is treated as if it were\n   \".git/config\".  HFS+ has a similar issue, where certain unicode\n   codepoints are ignored, e.g. \".g\\u200cit/config\" is treated as if\n   it were \".git/config\".  Pathnames with these potential issues are\n   rejected on the affected systems.  Git on systems that are not\n   affected by this issue (e.g. Linux) can also be configured to\n   reject them to ensure cross platform interoperability of the hosted\n   projects.\n\n * \"git fsck\" notices a tree object that records such a path that can\n   be confused with \".git\", and with receive.fsckObjects configuration\n   set to true, an attempt to \"git push\" such a tree object will be\n   rejected.  Such a path may not be a problem on some filesystems\n   but in order to protect those on HFS+ and on case insensitive\n   filesystems, this check is enabled on all platforms.\n\nA big \"thanks!\" for bringing this issue to us goes to our friends in\nthe Mercurial land, namely, Matt Mackall and Augie Fackler.\n\nAlso contains typofixes, documentation updates and trivial code clean-ups.\n\n----------------------------------------------------------------\n\nChanges since v2.2.0 are as follows:\n\nHartmut Henkel (1):\n      l10n: de.po: fix typos\n\nJeff King (8):\n      unpack-trees: propagate errors adding entries to the index\n      read-tree: add tests for confusing paths like \"..\" and \".git\"\n      verify_dotfile(): reject .git case-insensitively\n      t1450: refactor \".\", \"..\", and \".git\" fsck tests\n      fsck: notice .git case-insensitively\n      utf8: add is_hfs_dotgit() helper\n      read-cache: optionally disallow HFS+ .git variants\n      fsck: complain about HFS+ \".git\" aliases in trees\n\nJohannes Schindelin (3):\n      path: add is_ntfs_dotgit() helper\n      read-cache: optionally disallow NTFS .git variants\n      fsck: complain about NTFS \".git\" aliases in trees\n\nJunio C Hamano (6):\n      Start post 2.2 cycle\n      Git 1.8.5.6\n      Git 1.9.5\n      Git 2.0.5\n      Git 2.1.4\n      Git 2.2.1\n"},{"id":"253825","messageId":"CAF7_NFTwn5DcxJeRYHEUv5ae6-rh-8r7PXT81uOdPxvT2jtvug@mail.gmail.com","threadId":"38199","inReplyTo":"xmqq61d87jew.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2014-12-19T06:40:54Z","receivedAt":"2014-12-19T06:40:54Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"Hello. Thank you for the fix.\n\nWould it be more reliable to compare inode of directory in question\nand \".git\"? (there is [*] for windows). So that any unspotted name\nequivalence is prevented to cause any harm.\n\n*) http://stackoverflow.com/questions/7162164/does-windows-have-inode-numbers-like-linux\n"},{"id":"253828","messageId":"alpine.DEB.1.00.1412190955040.13845@s15462909.onlinehome-server.info","threadId":"38199","inReplyTo":"CAF7_NFTwn5DcxJeRYHEUv5ae6-rh-8r7PXT81uOdPxvT2jtvug@mail.gmail.com","subject":"Re: [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2014-12-19T09:18:16Z","receivedAt":"2014-12-19T09:18:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Max,\n\nOn Fri, 19 Dec 2014, Max Kirillov wrote:\n\n> Hello. Thank you for the fix.\n\nYou are welcome.\n\n> Would it be more reliable to compare inode of directory in question and\n> \".git\"? (there is [*] for windows). So that any unspotted name\n> equivalence is prevented to cause any harm.\n> \n> *) http://stackoverflow.com/questions/7162164/does-windows-have-inode-numbers-like-linux\n\nWe were considering this, really. The biggest problem we had with this\napproach is that the most important aspect of releasing a new version was\nto let hosting sites protect their users via receive.fsckObjects = true\n(which all hosting sites should activate anyway) by rejecting the\nill-intentioned file names in hand-crafted tree objects.\n\nThis turned out to be much more important than the user-facing aspect:\nmany users will not update (in many cases, users will be prevented by\nadministrators from updating their software themselves, even).\n\nTherefore, we really tried very hard to get the checks right without\nhaving to write out non-bare repositories on Windows (or for that matter,\non MacOSX).\n\nHaving said that, I would welcome additional safeguards on the users'\nside, such as what you suggested; I had written out the code in a mail\nthread between the Git security squad (in addition to nFileIndexHigh and\nnFileIndexLow, we need to check dwVolumeSerialNumber, too), maybe you want\nto take this further?\n\n-- snip --\nUntested code snippet to illustrate what I have in mind:\n\n\tstatic int is_git_directory(const char *path) {\n\t\tstatic int initialized;\n\t\tstatic DWORD dwVolumeSerialNumber, nFileSizeHigh, nFileSizeLow;\n\n\t\tHANDLE handle;\n\t\tBY_HANDLE_FILE_INFORMATION info;\n\t\tint result = 0;\n\n\t\tif (!initialized) {\n\t\t\thandle = CreateFile(get_git_dir(), 0,\n\t\t\t\tFILE_SHARE_READ, 0, OPEN_EXISTING,\n\t\t\t\tFILE_ATTRIBUTE_NORMAL);\n\n\t\t\tif (handle != INVALID_HANDLE_VALUE) {\n\t\t\t\tif (GetFileInformationByHandle(handle, &info)) {\n\t\t\t\t\tdwVolumeSerialNumber =\n\t\t\t\t\t\tinfo.dwVolumeSerialNumber;\n\t\t\t\t\tnFileSizeHigh = info.nFileSizeHigh;\n\t\t\t\t\tnFileSizeLow = info.nFileSizeLow;\n\t\t\t\t}\n\t\t\t\tCloseHandle(handle);\n\t\t\t}\n\t\t\tinitialized = 1;\n\t\t}\n\n\t\thandle = CreateFile(path, 0, FILE_SHARE_READ, 0, OPEN_EXISTING,\n\t\t\tFILE_ATTRIBUTE_NORMAL);\n\n\t\tif (handle != INVALID_HANDLE_VALUE) {\n\t\t\tif (GetFileInformationByHandle(handle, &info)) {\n\t\t\t\tresult = dwVolumeSerialNumber ==\n\t\t\t\t\tinfo.dwVolumeSerialNumber &&\n\t\t\t\t\tnFileSizeHigh == info.nFileSizeHigh &&\n\t\t\t\t\tnFileSizeLow == info.nFileSizeLow;\n\t\t\t}\n\t\t\tCloseHandle(handle);\n\t\t}\n\t\treturn result;\n\t}\n\n\tstatic inline int is_in_git_directory(const char *path) {\n\t\tchar *copy = xstrdup(path);\n\t\twhile (PathRemoveFileSpec(path)) {\n\t\t\tif (is_git_directory(path)) {\n\t\t\t\tfree(copy);\n\t\t\t\treturn 1;\n\t\t\t}\n\t\t}\n\t\tfree(copy);\n\t\treturn 0;\n\t}\n\nThis *should* be good enough.\n\nI fear that this will have a performance impact that might be alleviated\nby caching results.\n\nWhat do you think?\n-- snap --\n\nPlease note that this code has been written inside a mail program and has\nnever seen a compiler.\n\nThis function – `is_in_git_directory()` – would be called at the start of\n`verify_path()`, protected by an `if (protect_ntfs)` guard, and of course\nwe would need to have a POSIX version using inodes, too, because – believe\nit or not – there are Linux users using Git on NTFS volumes.\n\nThe problems I see with this are:\n\n1) it really might affect performance very negatively, as it has to\n   perform recursive checks for *all* the paths about to be checked out,\n\n2) we would really need to make sure that the function cannot be called\n   *before* initializing the .git/ directory in `git init` and `git clone`,\n   and\n\n3) it would not protect submodules' .git/ directories (before we switched\n   to writing out .git files redirecting to the super project's .git/\n   directory, Git initialized .git/ directories inside the submodules'\n   working directories).\n\nCiao,\nJohannes"}]}