Some links for understanding CVE-2014-9390

This is a particularly interesting CVE for me, because it's "right up my alley", as they say.

• Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land

  Git maintains various meta-information for its repository in files in .git/ directory located at the root of the working tree. The system does not allow a file in that directory (e.g. .git/config) to be committed in the history of the project, or checked out to the working tree from the project. Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker).

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

  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.
  

• 3f1509809e728b70ea7912e4e1b40f22965e45ee

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

• Git vulnerability with .git\config

  Normally the git client avoids ever overwriting that file. Even if you commit a .git\config file and push it to a shared repo, no one else’s Git client will check it out into their private repos. However, a bug was discovered where various permutations of the .git folder name (e.g. mixed case, gIT, GiT, etc, Windows filename shortening .git~123, Ignorable Unicode codepoints .g\u200cit\config, etc) were not caught be the Git client’s filtering logic. As such, if someone pushed a malicious config file with one of these permutations, other people’s Git clients would check them out, overwriting their personal config file and hijacking their Git commands. This affects, at least, Windows NTFS and Mac OS X HFS+ filesystems, both of which are case insensitive filesystems.

• Vulnerability announced: update your Git clients

  Repositories hosted on github.com cannot contain any of the malicious trees that trigger the vulnerability because we now verify and block these trees on push. We have also completed an automated scan of all existing content on github.com to look for malicious content that might have been pushed to our site before this vulnerability was discovered. This work is an extension of the data-quality checks we have always performed on repositories pushed to our servers to protect our users against malformed or malicious Git data.