Git v2.24.1 and others

The Git project has released Git v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6. "These releases fix various security flaws, which allowed an attacker to overwrite arbitrary paths, remotely execute code, and/or overwrite files in the .git/ directory etc." The release notes contained in this announcement have the details.

From:		Junio C Hamano <gitster-AT-pobox.com>
To:		git-AT-vger.kernel.org
Subject:		[ANNOUNCE] Git v2.24.1 and others
Date:		Tue, 10 Dec 2019 10:05:46 -0800
Message-ID:		<xmqqr21cqcn9.fsf@gitster-ct.c.googlers.com>
Cc:		Linux Kernel <linux-kernel-AT-vger.kernel.org>, git-packagers-AT-googlegroups.com
Archive-link:		Article

Today, the Git project is releasing the following Git versions:

    v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2,
    v2.17.3, v2.16.6, v2.15.4, and v2.14.6

These releases fix various security flaws, which allowed an attacker
to overwrite arbitrary paths, remotely execute code, and/or overwrite
files in the .git/ directory etc.  See the release notes attached for
the list for their descriptions and CVE identifiers.

Users of the affected maintenance tracks are urged to upgrade.

These flaws were discovered and reported by Joern Schneeweisz of
GitLab and by Microsoft Security Response Center (and in particular
Nicolas Joly), and were fixed by Johannes Schindelin, Jeff King,
Garima Singh and Jonathan Nieder on the git-security mailing list.
The release engineering and coordination was led by Johannes
Schindelin.

The tarballs are found at:

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

The following public repositories all have a copy of the 'v2.24.1'
and other tags:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git

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

Git v2.14.6 Release Notes
=========================

This release addresses the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387.

Fixes since v2.14.5
-------------------

 * CVE-2019-1348:
   The --export-marks option of git fast-import is exposed also via
   the in-stream command feature export-marks=... and it allows
   overwriting arbitrary paths.

 * CVE-2019-1349:
   When submodules are cloned recursively, under certain circumstances
   Git could be fooled into using the same Git directory twice. We now
   require the directory to be empty.

 * CVE-2019-1350:
   Incorrect quoting of command-line arguments allowed remote code
   execution during a recursive clone in conjunction with SSH URLs.

 * CVE-2019-1351:
   While the only permitted drive letters for physical drives on
   Windows are letters of the US-English alphabet, this restriction
   does not apply to virtual drives assigned via subst <letter>:
   <path>. Git mistook such paths for relative paths, allowing writing
   outside of the worktree while cloning.

 * CVE-2019-1352:
   Git was unaware of NTFS Alternate Data Streams, allowing files
   inside the .git/ directory to be overwritten during a clone.

 * CVE-2019-1353:
   When running Git in the Windows Subsystem for Linux (also known as
   "WSL") while accessing a working directory on a regular Windows
   drive, none of the NTFS protections were active.

 * CVE-2019-1354:
   Filenames on Linux/Unix can contain backslashes. On Windows,
   backslashes are directory separators. Git did not use to refuse to
   write out tracked files with such filenames.

 * CVE-2019-1387:
   Recursive clones are currently affected by a vulnerability that is
   caused by too-lax validation of submodule names, allowing very
   targeted attacks via remote code execution in recursive clones.

Credit for finding these vulnerabilities goes to Microsoft Security
Response Center, in particular to Nicolas Joly. The `fast-import`
fixes were provided by Jeff King, the other fixes by Johannes
Schindelin with help from Garima Singh.


Git v2.15.4 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6 to address
the security issues CVE-2019-1348, CVE-2019-1349, CVE-2019-1350,
CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, and
CVE-2019-1387; see the release notes for that version for details.

In conjunction with a vulnerability that was fixed in v2.20.2,
`.gitmodules` is no longer allowed to contain entries of the form
`submodule.<name>.update=!command`.


Git v2.16.6 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6 and in
v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
CVE-2019-1354, and CVE-2019-1387; see the release notes for those
versions for details.


Git v2.17.3 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6 and in
v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
CVE-2019-1354, and CVE-2019-1387; see the release notes for those
versions for details.

In addition, `git fsck` was taught to identify `.gitmodules` entries
of the form `submodule.<name>.update=!command`, which have been
disallowed in v2.15.4.


Git v2.18.2 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.


Git v2.19.3 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.


Git v2.20.2 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4
and in v2.17.3, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
for those versions for details.

The change to disallow `submodule.<name>.update=!command` entries in
`.gitmodules` which was introduced v2.15.4 (and for which v2.17.3
added explicit fsck checks) fixes the vulnerability in v2.20.x where a
recursive clone followed by a submodule update could execute code
contained within the repository without the user explicitly having
asked for that (CVE-2019-19604).

Credit for finding this vulnerability goes to Joern Schneeweisz,
credit for the fixes goes to Jonathan Nieder.


Git v2.21.1 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4,
v2.17.3 and in v2.20.2, addressing the security issues CVE-2019-1348,
CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and CVE-2019-19604;
see the release notes for those versions for details.

Additionally, this version also includes a couple of fixes for the
Windows-specific quoting of command-line arguments when Git executes
a Unix shell on Windows.


Git v2.22.2 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4,
v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
CVE-2019-19604; see the release notes for those versions for details.


Git v2.23.1 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4,
v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
CVE-2019-19604; see the release notes for those versions for details.


Git v2.24.1 Release Notes
=========================

This release merges up the fixes that appear in v2.14.6, v2.15.4,
v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
CVE-2019-19604; see the release notes for those versions for details.

Git v2.24.1 and others

Posted Dec 11, 2019 8:44 UTC (Wed) by bovinespirit (subscriber, #88348) [Link] (19 responses)

"Filenames on Linux/Unix can contain backslashes."

$ touch " eat:\ this Bash! "
$ for f in $(ls); do echo $f; done
eat:\
this
Bash!

So they can! I love/hate shell scripting!

Git v2.24.1 and others

Posted Dec 11, 2019 14:27 UTC (Wed) by Vorpal (guest, #136011) [Link] (15 responses)

They can also contain newlines. In fact the only disallowed characters by Linux are \0 (null bytes) and / (the path separator). Of course, certain file systems (such as vfat) can have additional restrictions.

Git v2.24.1 and others

Posted Dec 11, 2019 17:14 UTC (Wed) by nix (subscriber, #2304) [Link] (12 responses)

And, of course, Unicode lookalikes are still possible:

nix@loom 1179 ~/oracle/tmp/luci% ls -l foo*bar
-rw-rw-r-- 1 nix nix 0 Dec 11 17:13 foo⧸bar

(That's U+29F8 BIG SOLIDUS.)

Git v2.24.1 and others

Posted Dec 12, 2019 13:30 UTC (Thu) by epa (subscriber, #39769) [Link] (11 responses)

Another plug for Fixing Unix/Linux/POSIX Filenames, for those who have not yet read it.

Git v2.24.1 and others

Posted Dec 14, 2019 23:37 UTC (Sat) by adobriyan (subscriber, #30858) [Link] (10 responses)

The fix is to not use shell scripts for anything serious.

David Wheeler's logic is like this:
most shell scripts are buggy because shell authors make it easy to make mistakes despite knowing perfectly well that Unix allows whitespace in filenames, therefore OS kernel should accomodate shell users.

We've seen this pattern before:
shell can't do system calls therefore OS kernel should interface in text which is inferior in nearly any way.

Real programming languages (say Python) don't have the problem with whitespace (subprocess.call()).

Maybe it is the Unix shells that should be fixed?

Even if whitespace and other characters are banned where will they stop? Unicode is big, there are 8 newlines.

Git v2.24.1 and others

Posted Dec 15, 2019 0:11 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> Unicode is big, there are 8 newlines.
Unicode? What Unicode? Unix file names need not be Unicode in any encoding. They can be arbitrary binary garbage.

Getting filenames to be valid UTF-8 would be an awesome improvement over the status quo.

Git v2.24.1 and others

Posted Dec 15, 2019 11:43 UTC (Sun) by adobriyan (subscriber, #30858) [Link] (1 responses)

UTF-8 implies Unicode. People doing Unicode say that UTF-8 part is trivial and the hard part is at glyph/grapheme level.

Git v2.24.1 and others

Posted Dec 15, 2019 11:45 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Yet the filesystems fail even the trivial part..

Git v2.24.1 and others

Posted Dec 16, 2019 0:13 UTC (Mon) by zlynx (guest, #2285) [Link] (6 responses)

I am glad we have arbitrary binary garbage.

Otherwise Linux / Unix would have ended up like the others in love with "the future" and we'd be stuck with UCS-2 circa 2002. Which is neither big enough for every character, nor space efficient.

Won't it be fun in the year 2100 when users have to create wild WTF-8 hacks to work around the encoding limitations hard coded into their virtual storage backend.

Git v2.24.1 and others

Posted Dec 17, 2019 22:02 UTC (Tue) by flussence (guest, #85566) [Link] (3 responses)

Somehow I doubt the human race will fill up the other 90% of UTF-8 codepoints in less than 0.1% the time it took to invent the first 10%.

Git v2.24.1 and others

Posted Dec 18, 2019 12:06 UTC (Wed) by NAR (subscriber, #1313) [Link] (2 responses)

Aren't emojis using up UTF-8 codepoints? I can very well imagine the human race fill up the UTF-8 codepoints, unfortunately...

Git v2.24.1 and others

Posted Dec 20, 2019 0:33 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

The bulk of existing emojis came from a set already used among Japanese phone carriers around the turn of the century. That's why U+1F5FC is labelled the Tokyo (not Eiffel) Tower, and most of that block is similarly laden with cultural artifacts most people wouldn't be familiar with.

We're actually running out of things to add to Unicode. New emoji proposals are in short supply and most of the recent additions have been ancient scripts and increasingly obscure precomposed CJK glyphs. Maybe of more relevance to people reading this, Unicode 13 is adding characters from ancient computer systems (Spectrum, Teletext, C64 and the like): https://www.unicode.org/charts/PDF/Unicode-13.0/

Git v2.24.1 and others

Posted Dec 23, 2019 15:13 UTC (Mon) by geert (subscriber, #98403) [Link]

Looks like we're still lacking a few characters to run a C64 emulator in a terminal window? ;-)

Git v2.24.1 and others

Posted Dec 17, 2019 22:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

UCS-2 would have been an improvement over the binary garbage. And anyway, UTF-8 is now universal for actual languages and there's plenty of space for new ones.

Pretty much the only case where UTF-8 won't be enough is if the Earth join the Galactic Federation with FTL communications. But in this case I think that migration off UTF-8 would be a good problem to have.

Git v2.24.1 and others

Posted Dec 18, 2019 12:24 UTC (Wed) by jezuch (subscriber, #52988) [Link]

With things like this, there usully comes a time when you can say that the problem is basically solved. It was not in 2002, but it pretty much is now. Just be glad that Unicode took upon itself the very ungrateful task of developing a universal standard for text encoding, and that you didn't have to do that yourself. It's now done. We can finally use it to clean up the royal mess of all the previous attempts.

It's like with date handling: do not *ever* write your own date handling library; now that even Java got a decent support for it in its standard library, you don't have to be stupid like this anymore ;) And one standard is enough. We've got it solved, let's move on already.

Git v2.24.1 and others

Posted Dec 11, 2019 18:50 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

Besides the bytes 0x00 (NUL) and 0x2f (slash), filenames consisting of exactly zero, one, or two 0x2e (dot) bytes and nothing more are also reserved. Other than these, and a maximum length limit of one hardware page, there are AFAIK no other restrictions on filenames on the Linux VFS.

Git v2.24.1 and others

Posted Dec 15, 2019 16:52 UTC (Sun) by nix (subscriber, #2304) [Link]

One hardware page? Oh, that's interesting -- if there is no lower fixed constraint, you can construct filesystems on systems with big page sizes containing files that you can't access at all on systems with a smaller page size! Most unexpected.

Git v2.24.1 and others

Posted Dec 11, 2019 14:37 UTC (Wed) by abatters (✭ supporter ✭, #6932) [Link] (2 responses)

I find this useful to find some common problems in shell scripts:

https://www.shellcheck.net/

Git v2.24.1 and others

Posted Dec 11, 2019 18:56 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (1 responses)

That's a cool tool. I did notice one flaw: it reports the common problem of piping find ... -print output to xargs, recommending use of -print0. But it didn't flag the issue that for

find [path] [patterns] -print0 | xargs ...

xargs must be given the -0 option. It said "no problems found" when -print was changed to -print0.

Git v2.24.1 and others

Posted Dec 11, 2019 23:59 UTC (Wed) by pabs (subscriber, #43278) [Link]

Please file a feature request about detecting this. There is a large backlog of such requests, but they will get to it eventually.