Skip to main content

Browse the archive

swh:1:snp:47f1e8bb459169b0feb652a9c3d9cbabd8526d4a
sort by:
Revision Author Date Message Commit Date
7cdafca Johannes Schindelin 04 December 2019, 20:33:29 UTC Git 2.15.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 06 December 2019, 15:26:58 UTC
e904deb Jonathan Nieder 05 December 2019, 09:28:28 UTC submodule: reject submodule.update = !command in .gitmodules Since ac1fbbda2013 (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02), Git has been careful to avoid copying [submodule "foo"] update = !run an arbitrary scary command from .gitmodules to a repository's local config, copying in the setting 'update = none' instead. The gitmodules(5) manpage documents the intention: The !command form is intentionally ignored here for security reasons Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9 (submodule--helper: introduce new update-module-mode helper, 2018-08-13, first released in v2.20.0-rc0)), there are scenarios where we *don't* ignore it: if the config store contains no submodule.foo.update setting, the submodule-config API falls back to reading .gitmodules and the repository-supplied !command gets run after all. This was part of a general change over time in submodule support to read more directly from .gitmodules, since unlike .git/config it allows a project to change values between branches and over time (while still allowing .git/config to override things). But it was never intended to apply to this kind of dangerous configuration. The behavior change was not advertised in ee69b2a9's commit message and was missed in review. Let's take the opportunity to make the protection more robust, even in Git versions that are technically not affected: instead of quietly converting 'update = !command' to 'update = none', noisily treat it as an error. Allowing the setting but treating it as meaning something else was just confusing; users are better served by seeing the error sooner. Forbidding the construct makes the semantics simpler and means we can check for it in fsck (in a separate patch). As a result, the submodule-config API cannot read this value from .gitmodules under any circumstance, and we can declare with confidence For security reasons, the '!command' form is not accepted here. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 06 December 2019, 15:26:58 UTC
d3ac8c3 Johannes Schindelin 04 December 2019, 20:26:31 UTC Sync with 2.14.6 * maint-2.14: (28 commits) Git 2.14.6 mingw: handle `subst`-ed "DOS drives" mingw: refuse to access paths with trailing spaces or periods mingw: refuse to access paths with illegal characters unpack-trees: let merged_entry() pass through do_add_entry()'s errors quote-stress-test: offer to test quoting arguments for MSYS2 sh t6130/t9350: prepare for stringent Win32 path validation quote-stress-test: allow skipping some trials quote-stress-test: accept arguments to test via the command-line tests: add a helper to stress test argument quoting mingw: fix quoting of arguments Disallow dubiously-nested submodule git directories protect_ntfs: turn on NTFS protection by default path: also guard `.gitmodules` against NTFS Alternate Data Streams is_ntfs_dotgit(): speed it up mingw: disallow backslash characters in tree objects' file names path: safeguard `.git` against NTFS Alternate Streams Accesses clone --recurse-submodules: prevent name squatting on Windows is_ntfs_dotgit(): only verify the leading segment test-path-utils: offer to run a protectNTFS/protectHFS benchmark ... 06 December 2019, 15:26:55 UTC
66d2a61 Johannes Schindelin 04 December 2019, 18:58:46 UTC Git 2.14.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 06 December 2019, 15:26:15 UTC
2ddcccf Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'win32-accommodate-funny-drive-names' 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>`. To prevent targeted attacks against systems where "funny" drive letters such as `1` or `!` are assigned, let's handle them as regular drive letters on Windows. This fixes CVE-2019-1351. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:09 UTC
65d30a1 Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'win32-filenames-cannot-have-trailing-spaces-or-periods' On Windows, filenames cannot have trailing spaces or periods, when opening such paths, they are stripped automatically. Read: you can open the file `README` via the file name `README . . .`. This ambiguity can be used in combination with other security bugs to cause e.g. remote code execution during recursive clones. This patch series fixes that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:09 UTC
5532ebd Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'fix-mingw-quoting-bug' This patch fixes a vulnerability in the Windows-specific code where a submodule names ending in a backslash were quoted incorrectly, and that bug could be abused to insert command-line parameters e.g. to `ssh` in a recursive clone. Note: this bug is Windows-only, as we have to construct a command line for the process-to-spawn, unlike Linux/macOS, where `execv()` accepts an already-split command line. While at it, other quoting issues are fixed as well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:08 UTC
76a681c Johannes Schindelin 02 October 2019, 11:08:45 UTC Merge branch 'dubiously-nested-submodules' Recursive clones are currently affected by a vulnerability that is caused by too-lax validation of submodule names. This topic branch fixes that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:08 UTC
dd53ea7 Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'turn-on-protectntfs-by-default' This patch series makes it safe to use Git on Windows drives, even if running on a mounted network share or within the Windows Subsystem for Linux (WSL). This topic branch addresses CVE-2019-1353. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:08 UTC
7f3551d Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'disallow-dotgit-via-ntfs-alternate-data-streams' This patch series plugs an attack vector we had overlooked in our December 2014 work on `core.protectNTFS`. Essentially, the path `.git::$INDEX_ALLOCATION/config` is interpreted as `.git/config` when NTFS Alternate Data Streams are available (which they are on Windows, and at least on network shares that are SMB-mounted on macOS). Needless to say: we don't want that. In fact, we want to stay on the very safe side and not even special-case the `$INDEX_ALLOCATION` stream type: let's just prevent Git from touching _any_ explicitly specified Alternate Data Stream of `.git`. In essence, we'll prevent Git from tracking, or writing to, any path with a segment of the form `.git:<anything>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:07 UTC
f82a97e Johannes Schindelin 05 September 2019, 22:09:10 UTC mingw: handle `subst`-ed "DOS drives" Over a decade ago, in 25fe217b86c (Windows: Treat Windows style path names., 2008-03-05), Git was taught to handle absolute Windows paths, i.e. paths that start with a drive letter and a colon. Unbeknownst to us, while drive letters of physical drives are limited to letters of the English alphabet, there is a way to assign virtual drive letters to arbitrary directories, via the `subst` command, which is _not_ limited to English letters. It is therefore possible to have absolute Windows paths of the form `1:\what\the\hex.txt`. Even "better": pretty much arbitrary Unicode letters can also be used, e.g. `ä:\tschibät.sch`. While it can be sensibly argued that users who set up such funny drive letters really seek adverse consequences, the Windows Operating System is known to be a platform where many users are at the mercy of administrators who have their very own idea of what constitutes a reasonable setup. Therefore, let's just make sure that such funny paths are still considered absolute paths by Git, on Windows. In addition to Unicode characters, pretty much any character is a valid drive letter, as far as `subst` is concerned, even `:` and `"` or even a space character. While it is probably the opposite of smart to use them, let's safeguard `is_dos_drive_prefix()` against all of them. Note: `[::1]:repo` is a valid URL, but not a valid path on Windows. As `[` is now considered a valid drive letter, we need to be very careful to avoid misinterpreting such a string as valid local path in `url_is_local_not_ssh()`. To do that, we use the just-introduced function `is_valid_path()` (which will label the string as invalid file name because of the colon characters). This fixes CVE-2019-1351. Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:07 UTC
379e51d Johannes Schindelin 19 September 2019, 22:12:37 UTC quote-stress-test: offer to test quoting arguments for MSYS2 sh It is unfortunate that we need to quote arguments differently on Windows, depending whether we build a command-line for MSYS2's `sh` or for other Windows executables. We already have a test helper to verify the latter, with this patch we can also verify the former. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
7530a62 Johannes Schindelin 19 September 2019, 21:46:31 UTC quote-stress-test: allow skipping some trials When the, say, 93rd trial run fails, it is a good idea to have a way to skip the first 92 trials and dig directly into the 93rd in a debugger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
817ddd6 Johannes Schindelin 05 September 2019, 11:44:21 UTC mingw: refuse to access paths with illegal characters Certain characters are not admissible in file names on Windows, even if Cygwin/MSYS2 (and therefore, Git for Windows' Bash) pretend that they are, e.g. `:`, `<`, `>`, etc Let's disallow those characters explicitly in Windows builds of Git. Note: just like trailing spaces or periods, it _is_ possible on Windows to create commits adding files with such illegal characters, as long as the operation leaves the worktree untouched. To allow for that, we continue to guard `is_valid_win32_path()` behind the config setting `core.protectNTFS`, so that users _can_ continue to do that, as long as they turn the protections off via that config setting. Among other problems, this prevents Git from trying to write to an "NTFS Alternate Data Stream" (which refers to metadata stored alongside a file, under a special name: "<filename>:<stream-name>"). This fix therefore also prevents an attack vector that was exploited in demonstrations of a number of recently-fixed security bugs. Further reading on illegal characters in Win32 filenames: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
d2c84da Johannes Schindelin 05 September 2019, 11:27:53 UTC mingw: refuse to access paths with trailing spaces or periods When creating a directory on Windows whose path ends in a space or a period (or chains thereof), the Win32 API "helpfully" trims those. For example, `mkdir("abc ");` will return success, but actually create a directory called `abc` instead. This stems back to the DOS days, when all file names had exactly 8 characters plus exactly 3 characters for the file extension, and the only way to have shorter names was by padding with spaces. Sadly, this "helpful" behavior is a bit inconsistent: after a successful `mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because the directory `abc ` does not actually exist). Even if it would work, we now have a serious problem because a Git repository could contain directories `abc` and `abc `, and on Windows, they would be "merged" unintentionally. As these paths are illegal on Windows, anyway, let's disallow any accesses to such paths on that Operating System. For practical reasons, this behavior is still guarded by the config setting `core.protectNTFS`: it is possible (and at least two regression tests make use of it) to create commits without involving the worktree. In such a scenario, it is of course possible -- even on Windows -- to create such file names. Among other consequences, this patch disallows submodules' paths to end in spaces on Windows (which would formerly have confused Git enough to try to write into incorrect paths, anyway). While this patch does not fix a vulnerability on its own, it prevents an attack vector that was exploited in demonstrations of a number of recently-fixed security bugs. The regression test added to `t/t7417-submodule-path-url.sh` reflects that attack vector. Note that we have to adjust the test case "prevent git~1 squatting on Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue. It tries to clone two submodules whose names differ only in a trailing period character, and as a consequence their git directories differ in the same way. Previously, when Git tried to clone the second submodule, it thought that the git directory already existed (because on Windows, when you create a directory with the name `b.` it actually creates `b`), but with this patch, the first submodule's clone will fail because of the illegal name of the git directory. Therefore, when cloning the second submodule, Git will take a different code path: a fresh clone (without an existing git directory). Both code paths fail to clone the second submodule, both because the the corresponding worktree directory exists and is not empty, but the error messages are worded differently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
cc756ed Johannes Schindelin 09 September 2019, 11:56:15 UTC unpack-trees: let merged_entry() pass through do_add_entry()'s errors A `git clone` will end with exit code 0 when `merged_entry()` returns a positive value during a call of `unpack_trees()` to `traverse_trees()`. The reason is that `unpack_trees()` will interpret a positive value not to be an error. The problem is, however, that `add_index_entry()` (which is called by `merged_entry()` can report an error, and we really should fail the entire clone in such a case. Let's fix this problem, in preparation for a Windows-specific patch disallowing `mkdir()` with directory names that contain a trailing space (which is illegal on NTFS): we want `git clone` to abort when a path cannot be checked out due to that condition. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
35edce2 Johannes Schindelin 09 September 2019, 13:43:35 UTC t6130/t9350: prepare for stringent Win32 path validation On Windows, file names cannot contain asterisks nor newline characters. In an upcoming commit, we will make this limitation explicit, disallowing even the creation of commits that introduce such file names. However, in the test scripts touched by this patch, we _know_ that those paths won't be checked out, so we _want_ to allow such file names. Happily, the stringent path validation will be guarded via the `core.protectNTFS` flag, so all we need to do is to force that flag off temporarily. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:37:06 UTC
55953c7 Johannes Schindelin 20 September 2019, 17:09:39 UTC quote-stress-test: accept arguments to test via the command-line When the stress test reported a problem with quoting certain arguments, it is helpful to have a facility to play with those arguments in order to find out whether variations of those arguments are affected, too. Let's allow `test-run-command quote-stress-test -- <args>` to be used for that purpose. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:53 UTC
ad15592 Garima Singh 18 September 2019, 20:03:59 UTC tests: add a helper to stress test argument quoting On Windows, we have to do all the command-line argument quoting ourselves. Worse: we have to have two versions of said quoting, one for MSYS2 programs (which have their own dequoting rules) and the rest. We care mostly about the rest, and to make sure that that works, let's have a stress test that comes up with all kinds of awkward arguments, verifying that a spawned sub-process receives those unharmed. Signed-off-by: Garima Singh <garima.singh@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:52 UTC
6d86841 Johannes Schindelin 13 September 2019, 14:32:43 UTC mingw: fix quoting of arguments We need to be careful to follow proper quoting rules. For example, if an argument contains spaces, we have to quote them. Double-quotes need to be escaped. Backslashes need to be escaped, but only if they are followed by a double-quote character. We need to be _extra_ careful to consider the case where an argument ends in a backslash _and_ needs to be quoted: in this case, we append a double-quote character, i.e. the backslash now has to be escaped! The current code, however, fails to recognize that, and therefore can turn an argument that ends in a single backslash into a quoted argument that now ends in an escaped double-quote character. This allows subsequent command-line parameters to be split and part of them being mistaken for command-line options, e.g. through a maliciously-crafted submodule URL during a recursive clone. Technically, we would not need to quote _all_ arguments which end in a backslash _unless_ the argument needs to be quoted anyway. For example, `test\` would not need to be quoted, while `test \` would need to be. To keep the code simple, however, and therefore easier to reason about and ensure its correctness, we now _always_ quote an argument that ends in a backslash. This addresses CVE-2019-1350. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:51 UTC
9102f95 Johannes Schindelin 09 September 2019, 19:04:41 UTC protect_ntfs: turn on NTFS protection by default Back in the DOS days, in the FAT file system, file names always consisted of a base name of length 8 plus a file extension of length 3. Shorter file names were simply padded with spaces to the full 8.3 format. Later, the FAT file system was taught to support _also_ longer names, with an 8.3 "short name" as primary file name. While at it, the same facility allowed formerly illegal file names, such as `.git` (empty base names were not allowed), which would have the "short name" `git~1` associated with it. For backwards-compatibility, NTFS supports alternative 8.3 short filenames, too, even if starting with Windows Vista, they are only generated on the system drive by default. We addressed the problem that the `.git/` directory can _also_ be accessed via `git~1/` (when short names are enabled) in 2b4c6efc821 (read-cache: optionally disallow NTFS .git variants, 2014-12-16), i.e. since Git v1.9.5, by introducing the config setting `core.protectNTFS` and enabling it by default on Windows. In the meantime, Windows 10 introduced the "Windows Subsystem for Linux" (short: WSL), i.e. a way to run Linux applications/distributions in a thinly-isolated subsystem on Windows (giving rise to many a "2016 is the Year of Linux on the Desktop" jokes). WSL is getting increasingly popular, also due to the painless way Linux application can operate directly ("natively") on files on Windows' file system: the Windows drives are mounted automatically (e.g. `C:` as `/mnt/c/`). Taken together, this means that we now have to enable the safe-guards of Git v1.9.5 also in WSL: it is possible to access a `.git` directory inside `/mnt/c/` via the 8.3 name `git~1` (unless short name generation was disabled manually). Since regular Linux distributions run in WSL, this means we have to enable `core.protectNTFS` at least on Linux, too. To enable Services for Macintosh in Windows NT to store so-called resource forks, NTFS introduced "Alternate Data Streams". Essentially, these constitute additional metadata that are connected to (and copied with) their associated files, and they are accessed via pseudo file names of the form `filename:<stream-name>:<stream-type>`. In a recent patch, we extended `core.protectNTFS` to also protect against accesses via NTFS Alternate Data Streams, e.g. to prevent contents of the `.git/` directory to be "tracked" via yet another alternative file name. While it is not possible (at least by default) to access files via NTFS Alternate Data Streams from within WSL, the defaults on macOS when mounting network shares via SMB _do_ allow accessing files and directories in that way. Therefore, we need to enable `core.protectNTFS` on macOS by default, too, and really, on any Operating System that can mount network shares via SMB/CIFS. A couple of approaches were considered for fixing this: 1. We could perform a dynamic NTFS check similar to the `core.symlinks` check in `init`/`clone`: instead of trying to create a symbolic link in the `.git/` directory, we could create a test file and try to access `.git/config` via 8.3 name and/or Alternate Data Stream. 2. We could simply "flip the switch" on `core.protectNTFS`, to make it "on by default". The obvious downside of 1. is that it won't protect worktrees that were clone with a vulnerable Git version already. We considered patching code paths that check out files to check whether we're running on an NTFS system dynamically and persist the result in the repository-local config setting `core.protectNTFS`, but in the end decided that this solution would be too fragile, and too involved. The obvious downside of 2. is that everybody will have to "suffer" the performance penalty incurred from calling `is_ntfs_dotgit()` on every path, even in setups where. After the recent work to accelerate `is_ntfs_dotgit()` in most cases, it looks as if the time spent on validating ten million random file names increases only negligibly (less than 20ms, well within the standard deviation of ~50ms). Therefore the benefits outweigh the cost. Another downside of this is that paths that might have been acceptable previously now will be forbidden. Realistically, though, this is an improvement because public Git hosters already would reject any `git push` that contains such file names. Note: There might be a similar problem mounting HFS+ on Linux. However, this scenario has been considered unlikely and in light of the cost (in the aforementioned benchmark, `core.protectHFS = true` increased the time from ~440ms to ~610ms), it was decided _not_ to touch the default of `core.protectHFS`. This change addresses CVE-2019-1353. Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Helped-by: Garima Singh <garima.singh@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:51 UTC
3a85dc7 Johannes Schindelin 06 September 2019, 19:09:35 UTC is_ntfs_dotgit(): speed it up Previously, this function was written without focusing on speed, intending to make reviewing the code as easy as possible, to avoid any bugs in this critical code. Turns out: we can do much better on both accounts. With this patch, we make it as fast as this developer can make it go: - We avoid the call to `is_dir_sep()` and make all the character comparisons explicit. - We avoid the cost of calling `strncasecmp()` and unroll the test for `.git` and `git~1`, not even using `tolower()` because it is faster to compare against two constant values. - We look for `.git` and `.git~1` first thing, and return early if not found. - We also avoid calling a separate function for detecting chains of spaces and periods. Each of these improvements has a noticeable impact on the speed of `is_ntfs_dotgit()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:51 UTC
91bd465 Johannes Schindelin 28 August 2019, 10:22:17 UTC path: also guard `.gitmodules` against NTFS Alternate Data Streams We just safe-guarded `.git` against NTFS Alternate Data Stream-related attack vectors, and now it is time to do the same for `.gitmodules`. Note: In the added regression test, we refrain from verifying all kinds of variations between short names and NTFS Alternate Data Streams: as the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it is enough to test one in order to know that all of them are guarded against. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:51 UTC
a8dee3c Johannes Schindelin 01 October 2019, 21:27:18 UTC Disallow dubiously-nested submodule git directories Currently it is technically possible to let a submodule's git directory point right into the git dir of a sibling submodule. Example: the git directories of two submodules with the names `hippo` and `hippo/hooks` would be `.git/modules/hippo/` and `.git/modules/hippo/hooks/`, respectively, but the latter is already intended to house the former's hooks. In most cases, this is just confusing, but there is also a (quite contrived) attack vector where Git can be fooled into mistaking remote content for file contents it wrote itself during a recursive clone. Let's plug this bug. To do so, we introduce the new function `validate_submodule_git_dir()` which simply verifies that no git dir exists for any leading directories of the submodule name (if there are any). Note: this patch specifically continues to allow sibling modules names of the form `core/lib`, `core/doc`, etc, as long as `core` is not a submodule name. This fixes CVE-2019-1387. Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:51 UTC
7c3745f Johannes Schindelin 28 August 2019, 10:22:17 UTC path: safeguard `.git` against NTFS Alternate Streams Accesses Probably inspired by HFS' resource streams, NTFS supports "Alternate Data Streams": by appending `:<stream-name>` to the file name, information in addition to the file contents can be written and read, information that is copied together with the file (unless copied to a non-NTFS location). These Alternate Data Streams are typically used for things like marking an executable as having just been downloaded from the internet (and hence not necessarily being trustworthy). In addition to a stream name, a stream type can be appended, like so: `:<stream-name>:<stream-type>`. Unless specified, the default stream type is `$DATA` for files and `$INDEX_ALLOCATION` for directories. In other words, `.git::$INDEX_ALLOCATION` is a valid way to reference the `.git` directory! In our work in Git v2.2.1 to protect Git on NTFS drives under `core.protectNTFS`, we focused exclusively on NTFS short names, unaware of the fact that NTFS Alternate Data Streams offer a similar attack vector. Let's fix this. Seeing as it is better to be safe than sorry, we simply disallow paths referring to *any* NTFS Alternate Data Stream of `.git`, not just `::$INDEX_ALLOCATION`. This also simplifies the implementation. This closes CVE-2019-1352. Further reading about NTFS Alternate Data Streams: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3 Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:50 UTC
288a74b Johannes Schindelin 23 September 2019, 06:58:11 UTC is_ntfs_dotgit(): only verify the leading segment The config setting `core.protectNTFS` is specifically designed to work not only on Windows, but anywhere, to allow for repositories hosted on, say, Linux servers to be protected against NTFS-specific attack vectors. As a consequence, `is_ntfs_dotgit()` manually splits backslash-separated paths (but does not do the same for paths separated by forward slashes), under the assumption that the backslash might not be a valid directory separator on the _current_ Operating System. However, the two callers, `verify_path()` and `fsck_tree()`, are supposed to feed only individual path segments to the `is_ntfs_dotgit()` function. This causes a lot of duplicate scanning (and very inefficient scanning, too, as the inner loop of `is_ntfs_dotgit()` was optimized for readability rather than for speed. Let's simplify the design of `is_ntfs_dotgit()` by putting the burden of splitting the paths by backslashes as directory separators on the callers of said function. Consequently, the `verify_path()` function, which already splits the path by directory separators, now treats backslashes as directory separators _explicitly_ when `core.protectNTFS` is turned on, even on platforms where the backslash is _not_ a directory separator. Note that we have to repeat some code in `verify_path()`: if the backslash is not a directory separator on the current Operating System, we want to allow file names like `\`, but we _do_ want to disallow paths that are clearly intended to cause harm when the repository is cloned on Windows. The `fsck_tree()` function (the other caller of `is_ntfs_dotgit()`) now needs to look for backslashes in tree entries' names specifically when `core.protectNTFS` is turned on. While it would be tempting to completely disallow backslashes in that case (much like `fsck` reports names containing forward slashes as "full paths"), this would be overzealous: when `core.protectNTFS` is turned on in a non-Windows setup, backslashes are perfectly valid characters in file names while we _still_ want to disallow tree entries that are clearly designed to exploit NTFS-specific behavior. This simplification will make subsequent changes easier to implement, such as turning `core.protectNTFS` on by default (not only on Windows) or protecting against attack vectors involving NTFS Alternate Data Streams. Incidentally, this change allows for catching malicious repositories that contain tree entries of the form `dir\.gitmodules` already on the server side rather than only on the client side (and previously only on Windows): in contrast to `is_ntfs_dotgit()`, the `is_ntfs_dotgitmodules()` function already expects the caller to split the paths by directory separators. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:50 UTC
a62f9d1 Garima Singh 04 September 2019, 17:36:39 UTC test-path-utils: offer to run a protectNTFS/protectHFS benchmark In preparation to flipping the default on `core.protectNTFS`, let's have some way to measure the speed impact of this config setting reliably (and for comparison, the `core.protectHFS` config setting). For now, this is a manual performance benchmark: ./t/helper/test-path-utils protect_ntfs_hfs [arguments...] where the arguments are an optional number of file names to test with, optionally followed by minimum and maximum length of the random file names. The default values are one million, 3 and 20, respectively. Just like `sqrti()` in `bisect.c`, we introduce a very simple function to approximation the square root of a given value, in order to avoid having to introduce the first user of `<math.h>` in Git's source code. Note: this is _not_ implemented as a Unix shell script in t/perf/ because we really care about _very_ precise timings here, and Unix shell scripts are simply unsuited for precise and consistent benchmarking. Signed-off-by: Garima Singh <garima.singh@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 05 December 2019, 14:36:40 UTC
4778452 Johannes Schindelin 16 September 2019, 11:26:40 UTC Merge branch 'prevent-name-squatting-on-windows' This patch series fixes an issue where Git could formerly have been tricked into creating a `.git` file with an unexpected (and therefore unprotected) NTFS short name. Incidentally, it also fixes an issue where a tree entry containing a backslash could be tricked into following a symbolic link, i.e. Git could be tricked into writing files outside the worktree. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 04 December 2019, 12:23:22 UTC
a7b1ad3 Johannes Schindelin 03 October 2019, 18:44:34 UTC Merge branch 'jk/fast-import-unsafe' 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. This topic branch prevents the in-stream version, to prevent arbitrary file accesses by `git fast-import` streams coming from untrusted sources (e.g. in remote helpers that are based on `git fast-import`). This fixes CVE-2019-1348. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 04 December 2019, 12:23:22 UTC
525e7fb Johannes Schindelin 16 September 2019, 18:44:31 UTC path.c: document the purpose of `is_ntfs_dotgit()` Previously, this function was completely undocumented. It is worth, though, to explain what is going on, as it is not really obvious at all. Suggested-by: Garima Singh <garima.singh@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 04 December 2019, 12:20:05 UTC
e1d911d Johannes Schindelin 12 September 2019, 12:54:05 UTC mingw: disallow backslash characters in tree objects' file names The backslash character is not a valid part of a file name on Windows. Hence it is dangerous to allow writing files that were unpacked from tree objects, when the stored file name contains a backslash character: it will be misinterpreted as directory separator. This not only causes ambiguity when a tree contains a blob `a\b` and a tree `a` that contains a blob `b`, but it also can be used as part of an attack vector to side-step the careful protections against writing into the `.git/` directory during a clone of a maliciously-crafted repository. Let's prevent that, addressing CVE-2019-1354. Note: we guard against backslash characters in tree objects' file names _only_ on Windows (because on other platforms, even on those where NTFS volumes can be mounted, the backslash character is _not_ a directory separator), and _only_ when `core.protectNTFS = true` (because users might need to generate tree objects for other platforms, of course without touching the worktree, e.g. using `git update-index --cacheinfo`). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 04 December 2019, 12:20:05 UTC
0060fd1 Johannes Schindelin 12 September 2019, 12:20:39 UTC clone --recurse-submodules: prevent name squatting on Windows In addition to preventing `.git` from being tracked by Git, on Windows we also have to prevent `git~1` from being tracked, as the default NTFS short name (also known as the "8.3 filename") for the file name `.git` is `git~1`, otherwise it would be possible for malicious repositories to write directly into the `.git/` directory, e.g. a `post-checkout` hook that would then be executed _during_ a recursive clone. When we implemented appropriate protections in 2b4c6efc821 (read-cache: optionally disallow NTFS .git variants, 2014-12-16), we had analyzed carefully that the `.git` directory or file would be guaranteed to be the first directory entry to be written. Otherwise it would be possible e.g. for a file named `..git` to be assigned the short name `git~1` and subsequently, the short name generated for `.git` would be `git~2`. Or `git~3`. Or even `~9999999` (for a detailed explanation of the lengths we have to go to protect `.gitmodules`, see the commit message of e7cb0b4455c (is_ntfs_dotgit: match other .git files, 2018-05-11)). However, by exploiting two issues (that will be addressed in a related patch series close by), it is currently possible to clone a submodule into a non-empty directory: - On Windows, file names cannot end in a space or a period (for historical reasons: the period separating the base name from the file extension was not actually written to disk, and the base name/file extension was space-padded to the full 8/3 characters, respectively). Helpfully, when creating a directory under the name, say, `sub.`, that trailing period is trimmed automatically and the actual name on disk is `sub`. This means that while Git thinks that the submodule names `sub` and `sub.` are different, they both access `.git/modules/sub/`. - While the backslash character is a valid file name character on Linux, it is not so on Windows. As Git tries to be cross-platform, it therefore allows backslash characters in the file names stored in tree objects. Which means that it is totally possible that a submodule `c` sits next to a file `c\..git`, and on Windows, during recursive clone a file called `..git` will be written into `c/`, of course _before_ the submodule is cloned. Note that the actual exploit is not quite as simple as having a submodule `c` next to a file `c\..git`, as we have to make sure that the directory `.git/modules/b` already exists when the submodule is checked out, otherwise a different code path is taken in `module_clone()` that does _not_ allow a non-empty submodule directory to exist already. Even if we will address both issues nearby (the next commit will disallow backslash characters in tree entries' file names on Windows, and another patch will disallow creating directories/files with trailing spaces or periods), it is a wise idea to defend in depth against this sort of attack vector: when submodules are cloned recursively, we now _require_ the directory to be empty, addressing CVE-2019-1349. Note: the code path we patch is shared with the code path of `git submodule update --init`, which must not expect, in general, that the directory is empty. Hence we have to introduce the new option `--force-init` and hand it all the way down from `git submodule` to the actual `git submodule--helper` process that performs the initial clone. Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 04 December 2019, 12:20:05 UTC
a52ed76 Jeff King 29 August 2019, 19:08:42 UTC fast-import: disallow "feature import-marks" by default As with export-marks in the previous commit, import-marks can access the filesystem. This is significantly less dangerous than export-marks because it only involves reading from arbitrary paths, rather than writing them. However, it could still be surprising and have security implications (e.g., exfiltrating data from a service that accepts fast-import streams). Let's lump it (and its "if-exists" counterpart) in with export-marks, and enable the in-stream version only if --allow-unsafe-features is set. Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:04 UTC
68061e3 Jeff King 29 August 2019, 18:37:26 UTC fast-import: disallow "feature export-marks" by default The fast-import stream command "feature export-marks=<path>" lets the stream write marks to an arbitrary path. This may be surprising if you are running fast-import against an untrusted input (which otherwise cannot do anything except update Git objects and refs). Let's disallow the use of this feature by default, and provide a command-line option to re-enable it (you can always just use the command-line --export-marks as well, but the in-stream version provides an easy way for exporters to control the process). This is a backwards-incompatible change, since the default is flipping to the new, safer behavior. However, since the main users of the in-stream versions would be import/export-based remote helpers, and since we trust remote helpers already (which are already running arbitrary code), we'll pass the new option by default when reading a remote helper's stream. This should minimize the impact. Note that the implementation isn't totally simple, as we have to work around the fact that fast-import doesn't parse its command-line options until after it has read any "feature" lines from the stream. This is how it lets command-line options override in-stream. But in our case, it's important to parse the new --allow-unsafe-features first. There are three options for resolving this: 1. Do a separate "early" pass over the options. This is easy for us to do because there are no command-line options that allow the "unstuck" form (so there's no chance of us mistaking an argument for an option), though it does introduce a risk of incorrect parsing later (e.g,. if we convert to parse-options). 2. Move the option parsing phase back to the start of the program, but teach the stream-reading code never to override an existing value. This is tricky, because stream "feature" lines override each other (meaning we'd have to start tracking the source for every option). 3. Accept that we might parse a "feature export-marks" line that is forbidden, as long we don't _act_ on it until after we've parsed the command line options. This would, in fact, work with the current code, but only because the previous patch fixed the export-marks parser to avoid touching the filesystem. So while it works, it does carry risk of somebody getting it wrong in the future in a rather subtle and unsafe way. I've gone with option (1) here as simple, safe, and unlikely to cause regressions. This fixes CVE-2019-1348. Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:04 UTC
0196830 Jeff King 29 August 2019, 17:33:48 UTC fast-import: delay creating leading directories for export-marks When we parse the --export-marks option, we don't immediately open the file, but we do create any leading directories. This can be especially confusing when a command-line option overrides an in-stream one, in which case we'd create the leading directory for the in-stream file, even though we never actually write the file. Let's instead create the directories just before opening the file, which means we'll create only useful directories. Note that this could change the handling of relative paths if we chdir() in between, but we don't actually do so; the only permanent chdir is from setup_git_directory() which runs before either code path (potentially we should take the pre-setup dir into account to avoid surprising the user, but that's an orthogonal change). The test just adapts the existing "override" test to use paths with leading directories. This checks both that the correct directory is created (which worked before but was not tested), and that the overridden one is not (our new fix here). While we're here, let's also check the error result of safe_create_leading_directories(). We'd presumably notice any failure immediately after when we try to open the file itself, but we can give a more specific error message in this case. Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:04 UTC
e075dba Jeff King 29 August 2019, 17:07:04 UTC fast-import: stop creating leading directories for import-marks When asked to import marks from "subdir/file.marks", we create the leading directory "subdir" if it doesn't exist. This makes no sense for importing marks, where we only ever open the path for reading. Most of the time this would be a noop, since if the marks file exists, then the leading directories exist, too. But if it doesn't (e.g., because --import-marks-if-exists was used), then we'd create the useless directory. This dates back to 580d5f83e7 (fast-import: always create marks_file directories, 2010-03-29). Even then it was useless, so it seems to have been added in error alongside the --export-marks case (which _is_ helpful). Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:04 UTC
11e934d Jeff King 29 August 2019, 15:25:45 UTC fast-import: tighten parsing of boolean command line options We parse options like "--max-pack-size=" using skip_prefix(), which makes sense to get at the bytes after the "=". However, we also parse "--quiet" and "--stats" with skip_prefix(), which allows things like "--quiet-nonsense" to behave like "--quiet". This was a mistaken conversion in 0f6927c229 (fast-import: put option parsing code in separate functions, 2009-12-04). Let's tighten this to an exact match, which was the original intent. Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:04 UTC
816f806 Jeff King 29 August 2019, 17:43:23 UTC t9300: create marks files for double-import-marks test Our tests confirm that providing two "import-marks" options in a fast-import stream is an error. However, the invoked command would fail even without covering this case, because the marks files themselves do not actually exist. Let's create the files to make sure we fail for the right reason (we actually do, because the option parsing happens before we open anything, but this future-proofs our test). Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:03 UTC
f94804c Jeff King 29 August 2019, 15:19:18 UTC t9300: drop some useless uses of cat These waste a process, and make the line longer than it needs to be. Signed-off-by: Jeff King <peff@peff.net> 04 December 2019, 12:20:03 UTC
924c623 Junio C Hamano 27 September 2018, 18:33:47 UTC Git 2.15.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:33:47 UTC
902df9f Junio C Hamano 27 September 2018, 18:20:22 UTC Sync with Git 2.14.4 * maint-2.14: Git 2.14.5 submodule-config: ban submodule paths that start with a dash submodule-config: ban submodule urls that start with dash submodule--helper: use "--" to signal end of clone options 27 September 2018, 18:20:22 UTC
d0832b2 Junio C Hamano 27 September 2018, 18:19:11 UTC Git 2.14.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 18:19:11 UTC
273c614 Jeff King 24 September 2018, 08:39:55 UTC submodule-config: ban submodule paths that start with a dash We recently banned submodule urls that look like command-line options. This is the matching change to ban leading-dash paths. As with the urls, this should not break any use cases that currently work. Even with our "--" separator passed to git-clone, git-submodule.sh gets confused. Without the code portion of this patch, the clone of "-sub" added in t7417 would yield results like: /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s /path/to/git-submodule: 410: cd: Illegal option -s /path/to/git-submodule: 417: cd: Illegal option -s Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed. Moreover, naively adding such a submodule doesn't work: $ git submodule add $url -sub The following path is ignored by one of your .gitignore files: -sub even though there is no such ignore pattern (the test script hacks around this with a well-placed "git mv"). Unlike leading-dash urls, though, it's possible that such a path _could_ be useful if we eventually made it work. So this commit should be seen not as recommending a particular policy, but rather temporarily closing off a broken and possibly dangerous code-path. We may revisit this decision later. There are two minor differences to the tests in t7416 (that covered urls): 1. We don't have a "./-sub" escape hatch to make this work, since the submodule code expects to be able to match canonical index names to the path field (so you are free to add submodule config with that path, but we would never actually use it, since an index entry would never start with "./"). 2. After this patch, cloning actually succeeds. Since we ignore the submodule.*.path value, we fail to find a config stanza for our submodule at all, and simply treat it as inactive. We still check for the "ignoring" message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:59 UTC
f6adec4 Jeff King 24 September 2018, 08:36:30 UTC submodule-config: ban submodule urls that start with dash The previous commit taught the submodule code to invoke our "git clone $url $path" with a "--" separator so that we aren't confused by urls or paths that start with dashes. However, that's just one code path. It's not clear if there are others, and it would be an easy mistake to add one in the future. Moreover, even with the fix in the previous commit, it's quite hard to actually do anything useful with such an entry. Any url starting with a dash must fall into one of three categories: - it's meant as a file url, like "-path". But then any clone is not going to have the matching path, since it's by definition relative inside the newly created clone. If you spell it as "./-path", the submodule code sees the "/" and translates this to an absolute path, so it at least works (assuming the receiver has the same filesystem layout as you). But that trick does not apply for a bare "-path". - it's meant as an ssh url, like "-host:path". But this already doesn't work, as we explicitly disallow ssh hostnames that begin with a dash (to avoid option injection against ssh). - it's a remote-helper scheme, like "-scheme::data". This _could_ work if the receiver bends over backwards and creates a funny-named helper like "git-remote--scheme". But normally there would not be any helper that matches. Since such a url does not work today and is not likely to do anything useful in the future, let's simply disallow them entirely. That protects the existing "git clone" path (in a belt-and-suspenders way), along with any others that might exist. Our tests cover two cases: 1. A file url with "./" continues to work, showing that there's an escape hatch for people with truly silly repo names. 2. A url starting with "-" is rejected. Note that we expect case (2) to fail, but it would have done so even without this commit, for the reasons given above. So instead of just expecting failure, let's also check for the magic word "ignoring" on stderr. That lets us know that we failed for the right reason. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:58 UTC
98afac7 Jeff King 24 September 2018, 08:32:15 UTC submodule--helper: use "--" to signal end of clone options When we clone a submodule, we call "git clone $url $path". But there's nothing to say that those components can't begin with a dash themselves, confusing git-clone into thinking they're options. Let's pass "--" to make it clear what we expect. There's no test here, because it's actually quite hard to make these names work, even with "git clone" parsing them correctly. And we're going to restrict these cases even further in future commits. So we'll leave off testing until then; this is just the minimal fix to prevent us from doing something stupid with a badly formed entry. Reported-by: joernchen <joernchen@phenoelit.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 September 2018, 16:34:55 UTC
d33c875 Junio C Hamano 22 May 2018, 05:15:59 UTC Git 2.15.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2018, 05:15:59 UTC
9e0f06d Junio C Hamano 22 May 2018, 05:15:14 UTC Sync with Git 2.14.4 * maint-2.14: Git 2.14.4 Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths 22 May 2018, 05:15:14 UTC
4dde7b8 Junio C Hamano 22 May 2018, 05:12:02 UTC Git 2.14.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2018, 05:12:02 UTC
7b01c71 Junio C Hamano 22 May 2018, 05:10:49 UTC Sync with Git 2.13.7 * maint-2.13: Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths 22 May 2018, 05:10:49 UTC
0114f71 Junio C Hamano 22 May 2018, 04:50:36 UTC Git 2.13.7 Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2018, 04:50:36 UTC
8528c31 Junio C Hamano 22 May 2018, 04:48:26 UTC Merge branch 'jk/submodule-fix-loose' into maint-2.13 * jk/submodule-fix-loose: verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths 22 May 2018, 04:48:26 UTC
10ecfa7 Jeff King 05 May 2018, 00:03:35 UTC verify_path: disallow symlinks in .gitmodules There are a few reasons it's not a good idea to make .gitmodules a symlink, including: 1. It won't be portable to systems without symlinks. 2. It may behave inconsistently, since Git may look at this file in the index or a tree without bothering to resolve any symbolic links. We don't do this _yet_, but the config infrastructure is there and it's planned for the future. With some clever code, we could make (2) work. And some people may not care about (1) if they only work on one platform. But there are a few security reasons to simply disallow it: a. A symlinked .gitmodules file may circumvent any fsck checks of the content. b. Git may read and write from the on-disk file without sanity checking the symlink target. So for example, if you link ".gitmodules" to "../oops" and run "git submodule add", we'll write to the file "oops" outside the repository. Again, both of those are problems that _could_ be solved with sufficient code, but given the complications in (1) and (2), we're better off just outlawing it explicitly. Note the slightly tricky call to verify_path() in update-index's update_one(). There we may not have a mode if we're not updating from the filesystem (e.g., we might just be removing the file). Passing "0" as the mode there works fine; since it's not a symlink, we'll just skip the extra checks. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
eb12dd0 Jeff King 14 May 2018, 15:00:56 UTC update-index: stat updated files earlier In the update_one(), we check verify_path() on the proposed path before doing anything else. In preparation for having verify_path() look at the file mode, let's stat the file earlier, so we can check the mode accurately. This is made a bit trickier by the fact that this function only does an lstat in a few code paths (the ones that flow down through process_path()). So we can speculatively do the lstat() here and pass the results down, and just use a dummy mode for cases where we won't actually be updating the index from the filesystem. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
641084b Jeff King 15 May 2018, 13:56:50 UTC verify_dotfile: mention case-insensitivity in comment We're more restrictive than we need to be in matching ".GIT" on case-sensitive filesystems; let's make a note that this is intentional. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
e19e5e6 Jeff King 13 May 2018, 17:00:23 UTC verify_path: drop clever fallthrough We check ".git" and ".." in the same switch statement, and fall through the cases to share the end-of-component check. While this saves us a line or two, it makes modifying the function much harder. Let's just write it out. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
41a8092 Jeff King 13 May 2018, 16:57:14 UTC skip_prefix: add case-insensitive variant We have the convenient skip_prefix() helper, but if you want to do case-insensitive matching, you're stuck doing it by hand. We could add an extra parameter to the function to let callers ask for this, but the function is small and somewhat performance-critical. Let's just re-implement it for the case-insensitive version. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
dc2d9ba Johannes Schindelin 12 May 2018, 20:16:51 UTC is_{hfs,ntfs}_dotgitmodules: add tests This tests primarily for NTFS issues, but also adds one example of an HFS+ issue. Thanks go to Congyi Wu for coming up with the list of examples where NTFS would possibly equate the filename with `.gitmodules`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
e7cb0b4 Johannes Schindelin 11 May 2018, 14:03:54 UTC is_ntfs_dotgit: match other .git files When we started to catch NTFS short names that clash with .git, we only looked for GIT~1. This is sufficient because we only ever clone into an empty directory, so .git is guaranteed to be the first subdirectory or file in that directory. However, even with a fresh clone, .gitmodules is *not* necessarily the first file to be written that would want the NTFS short name GITMOD~1: a malicious repository can add .gitmodul0000 and friends, which sorts before `.gitmodules` and is therefore checked out *first*. For that reason, we have to test not only for ~1 short names, but for others, too. It's hard to just adapt the existing checks in is_ntfs_dotgit(): since Windows 2000 (i.e., in all Windows versions still supported by Git), NTFS short names are only generated in the <prefix>~<number> form up to number 4. After that, a *different* prefix is used, calculated from the long file name using an undocumented, but stable algorithm. For example, the short name of .gitmodules would be GITMOD~1, but if it is taken, and all of ~2, ~3 and ~4 are taken, too, the short name GI7EBA~1 will be used. From there, collisions are handled by incrementing the number, shortening the prefix as needed (until ~9999999 is reached, in which case NTFS will not allow the file to be created). We'd also want to handle .gitignore and .gitattributes, which suffer from a similar problem, using the fall-back short names GI250A~1 and GI7D29~1, respectively. To accommodate for that, we could reimplement the hashing algorithm, but it is just safer and simpler to provide the known prefixes. This algorithm has been reverse-engineered and described at https://usn.pw/blog/gen/2015/06/09/filenames/, which is defunct but still available via https://web.archive.org/. These can be recomputed by running the following Perl script: -- snip -- use warnings; use strict; sub compute_short_name_hash ($) { my $checksum = 0; foreach (split('', $_[0])) { $checksum = ($checksum * 0x25 + ord($_)) & 0xffff; } $checksum = ($checksum * 314159269) & 0xffffffff; $checksum = 1 + (~$checksum & 0x7fffffff) if ($checksum & 0x80000000); $checksum -= (($checksum * 1152921497) >> 60) * 1000000007; return scalar reverse sprintf("%x", $checksum & 0xffff); } print compute_short_name_hash($ARGV[0]); -- snap -- E.g., running that with the argument ".gitignore" will result in "250a" (which then becomes "gi250a" in the code). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
0fc333b Jeff King 02 May 2018, 19:23:45 UTC is_hfs_dotgit: match other .git files Both verify_path() and fsck match ".git", ".GIT", and other variants specific to HFS+. Let's allow matching other special files like ".gitmodules", which we'll later use to enforce extra restrictions via verify_path() and fsck. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
11a9f4d Jeff King 13 May 2018, 16:09:42 UTC is_ntfs_dotgit: use a size_t for traversing string We walk through the "name" string using an int, which can wrap to a negative value and cause us to read random memory before our array (e.g., by creating a tree with a name >2GB, since "int" is still 32 bits even on most 64-bit platforms). Worse, this is easy to trigger during the fsck_tree() check, which is supposed to be protecting us from malicious garbage. Note one bit of trickiness in the existing code: we sometimes assign -1 to "len" at the end of the loop, and then rely on the "len++" in the for-loop's increment to take it back to 0. This is still legal with a size_t, since assigning -1 will turn into SIZE_MAX, which then wraps around to 0 on increment. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
0383bbb Jeff King 30 April 2018, 07:25:25 UTC submodule-config: verify submodule names as paths Submodule "names" come from the untrusted .gitmodules file, but we blindly append them to $GIT_DIR/modules to create our on-disk repo paths. This means you can do bad things by putting "../" into the name (among other things). Let's sanity-check these names to avoid building a path that can be exploited. There are two main decisions: 1. What should the allowed syntax be? It's tempting to reuse verify_path(), since submodule names typically come from in-repo paths. But there are two reasons not to: a. It's technically more strict than what we need, as we really care only about breaking out of the $GIT_DIR/modules/ hierarchy. E.g., having a submodule named "foo/.git" isn't actually dangerous, and it's possible that somebody has manually given such a funny name. b. Since we'll eventually use this checking logic in fsck to prevent downstream repositories, it should be consistent across platforms. Because verify_path() relies on is_dir_sep(), it wouldn't block "foo\..\bar" on a non-Windows machine. 2. Where should we enforce it? These days most of the .gitmodules reads go through submodule-config.c, so I've put it there in the reading step. That should cover all of the C code. We also construct the name for "git submodule add" inside the git-submodule.sh script. This is probably not a big deal for security since the name is coming from the user anyway, but it would be polite to remind them if the name they pick is invalid (and we need to expose the name-checker to the shell anyway for our test scripts). This patch issues a warning when reading .gitmodules and just ignores the related config entry completely. This will generally end up producing a sensible error, as it works the same as a .gitmodules file which is missing a submodule entry (so "submodule update" will barf, but "git clone --recurse-submodules" will print an error but not abort the clone. There is one minor oddity, which is that we print the warning once per malformed config key (since that's how the config subsystem gives us the entries). So in the new test, for example, the user would see three warnings. That's OK, since the intent is that this case should never come up outside of malicious repositories (and then it might even benefit the user to see the message multiple times). Credit for finding this vulnerability and the proof of concept from which the test script was adapted goes to Etienne Stalmans. Signed-off-by: Jeff King <peff@peff.net> 22 May 2018, 03:50:11 UTC
3013dff Junio C Hamano 06 December 2017, 17:10:35 UTC Prepare for 2.15.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 December 2017, 17:10:35 UTC
03d4bc1 Junio C Hamano 06 December 2017, 17:09:05 UTC Merge branch 'jc/merge-base-fork-point-doc' into maint Clarify and enhance documentation for "merge-base --fork-point", as it was clear what it computed but not why/what for. * jc/merge-base-fork-point-doc: merge-base --fork-point doc: clarify the example and failure modes 06 December 2017, 17:09:05 UTC
ce73209 Junio C Hamano 06 December 2017, 17:09:04 UTC Merge branch 'tz/redirect-fix' into maint A few scripts (both in production and tests) incorrectly redirected their error output. These have been corrected. * tz/redirect-fix: rebase: fix stderr redirect in apply_autostash() t/lib-gpg: fix gpgconf stderr redirect to /dev/null 06 December 2017, 17:09:04 UTC
0cfcb16 Junio C Hamano 06 December 2017, 17:09:04 UTC Merge branch 'tz/notes-error-to-stderr' into maint "git notes" sent its error message to its standard output stream, which was corrected. * tz/notes-error-to-stderr: notes: send "Automatic notes merge failed" messages to stderr 06 December 2017, 17:09:04 UTC
2ace172 Junio C Hamano 06 December 2017, 17:09:03 UTC Merge branch 'sb/test-cherry-pick-submodule-getting-in-a-way' into maint The three-way merge performed by "git cherry-pick" was confused when a new submodule was added in the meantime, which has been fixed (or "papered over"). * sb/test-cherry-pick-submodule-getting-in-a-way: merge-recursive: handle addition of submodule on our side of history t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure 06 December 2017, 17:09:03 UTC
0175b6e Junio C Hamano 06 December 2017, 17:09:03 UTC Merge branch 'pw/sequencer-recover-from-unlockable-index' into maint The sequencer machinery (used by "git cherry-pick A..B", and "git rebase -i", among other things) would have lost a commit if stopped due to an unlockable index file, which has been fixed. * pw/sequencer-recover-from-unlockable-index: sequencer: reschedule pick if index can't be locked 06 December 2017, 17:09:03 UTC
43240cb Junio C Hamano 06 December 2017, 17:09:03 UTC Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line' into maint "git apply --inaccurate-eof" when used with "--ignore-space-change" triggered an internal sanity check, which has been fixed. * rs/apply-inaccurate-eof-with-incomplete-line: apply: update line lengths for --inaccurate-eof 06 December 2017, 17:09:03 UTC
2db93a8 Junio C Hamano 06 December 2017, 17:09:02 UTC Merge branch 'tz/complete-branch-copy' into maint Command line completion (in contrib/) has been taught about the "--copy" option of "git branch". * tz/complete-branch-copy: completion: add '--copy' option to 'git branch' 06 December 2017, 17:09:02 UTC
3cc60ec Junio C Hamano 06 December 2017, 17:09:01 UTC Merge branch 'ew/rebase-mboxrd' into maint When "git rebase" prepared an mailbox of changes and fed it to "git am" to replay them, it was confused when a stray "From " happened to be in the log message of one of the replayed changes. This has been corrected. * ew/rebase-mboxrd: rebase: use mboxrd format to avoid split errors 06 December 2017, 17:09:01 UTC
74d6c9d Junio C Hamano 06 December 2017, 17:09:01 UTC Merge branch 'sd/branch-copy' into maint Code clean-up. * sd/branch-copy: config: avoid "write_in_full(fd, buf, len) != len" pattern 06 December 2017, 17:09:01 UTC
0114a7a Junio C Hamano 06 December 2017, 17:09:00 UTC Merge branch 'sw/pull-ipv46-passthru' into maint Contrary to the documentation, "git pull -4/-6 other-args" did not ask the underlying "git fetch" to go over IPv4/IPv6, which has been corrected. * sw/pull-ipv46-passthru: pull: pass -4/-6 option to 'git fetch' 06 December 2017, 17:09:00 UTC
3cdea38 Junio C Hamano 06 December 2017, 17:08:59 UTC Merge branch 'bc/submitting-patches-in-asciidoc' into maint The SubmittingPatches document has been converted to produce an HTML version via AsciiDoc/Asciidoctor. * bc/submitting-patches-in-asciidoc: Documentation: convert SubmittingPatches to AsciiDoc Documentation: enable compat-mode for Asciidoctor 06 December 2017, 17:08:59 UTC
02abc6b Junio C Hamano 06 December 2017, 17:08:20 UTC Merge branch 'mh/avoid-rewriting-packed-refs' into maint Recent update to the refs infrastructure implementation started rewriting packed-refs file more often than before; this has been optimized again for most trivial cases. * mh/avoid-rewriting-packed-refs: files-backend: don't rewrite the `packed-refs` file unnecessarily t1409: check that `packed-refs` is not rewritten unnecessarily 06 December 2017, 17:08:50 UTC
9b185be Junio C Hamano 28 November 2017, 04:39:14 UTC Git 2.15.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 November 2017, 04:39:14 UTC
b201e96 Junio C Hamano 28 November 2017, 04:38:33 UTC Merge branch 'rs/config-write-section-fix' into maint There was a recent semantic mismerge in the codepath to write out a section of a configuration section, which has been corrected. * rs/config-write-section-fix: config: flip return value of write_section() 28 November 2017, 04:38:33 UTC
7bc7776 Junio C Hamano 27 November 2017, 01:58:31 UTC A bit more fixes for 2.15.1 We've been waiting long enough, a few more would not hurt ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2017, 01:58:31 UTC
80a0e0f Junio C Hamano 27 November 2017, 01:57:02 UTC Merge branch 'ma/reduce-heads-leakfix' into maint Leak fixes. * ma/reduce-heads-leakfix: reduce_heads: fix memory leaks builtin/merge-base: free commit lists 27 November 2017, 01:57:02 UTC
03e8004 Junio C Hamano 27 November 2017, 01:57:02 UTC Merge branch 'ma/bisect-leakfix' into maint Leak fixes. * ma/bisect-leakfix: bisect: fix memory leak when returning best element bisect: fix off-by-one error in `best_bisection_sorted()` bisect: fix memory leak in `find_bisection()` bisect: change calling-convention of `find_bisection()` 27 November 2017, 01:57:02 UTC
df481b9 Junio C Hamano 27 November 2017, 01:57:02 UTC Merge branch 'rs/apply-fuzzy-match-fix' into maint A fix for an ancient bug in "git apply --ignore-space-change" codepath. * rs/apply-fuzzy-match-fix: apply: avoid out-of-bounds access in fuzzy_matchlines() 27 November 2017, 01:57:02 UTC
b51df7d Junio C Hamano 27 November 2017, 01:57:01 UTC Merge branch 'ad/submitting-patches-title-decoration' into maint Doc update around use of "format-patch --subject-prefix" etc. * ad/submitting-patches-title-decoration: doc/SubmittingPatches: correct subject guidance 27 November 2017, 01:57:01 UTC
95bf615 Junio C Hamano 27 November 2017, 01:57:00 UTC Merge branch 'rs/imap-send-next-arg-fix' into maint Error checking in "git imap-send" for empty response has been improved. * rs/imap-send-next-arg-fix: imap-send: handle missing response codes gracefully imap-send: handle NULL return of next_arg() 27 November 2017, 01:57:00 UTC
7d22aec Todd Zullinger 25 November 2017, 17:32:40 UTC RelNotes: minor typo fixes in 2.15.1 draft Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 November 2017, 03:49:23 UTC
95a731c Junio C Hamano 21 November 2017, 05:07:08 UTC Almost ready for 2.15.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 November 2017, 05:07:08 UTC
1c89be1 Junio C Hamano 21 November 2017, 05:05:33 UTC Merge branch 'rs/sequencer-rewrite-file-cleanup' into maint Code cleanup. * rs/sequencer-rewrite-file-cleanup: sequencer.c: check return value of close() in rewrite_file() sequencer: use O_TRUNC to truncate files sequencer: factor out rewrite_file() 21 November 2017, 05:05:33 UTC
01e0c53 Junio C Hamano 21 November 2017, 05:05:33 UTC Merge branch 'cb/t4201-robustify' into maint A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust 21 November 2017, 05:05:33 UTC
b2a2768 Junio C Hamano 21 November 2017, 05:05:32 UTC Merge branch 'tz/fsf-address-update' into maint Replace the mailing address of FSF to a URL, as FSF prefers. * tz/fsf-address-update: Replace Free Software Foundation address in license notices Replace Free Software Foundation address in license notices 21 November 2017, 05:05:32 UTC
8ff22f5 Junio C Hamano 21 November 2017, 05:05:32 UTC Merge branch 'ad/rebase-i-serie-typofix' into maint Typofix. * ad/rebase-i-serie-typofix: rebase -i: fix comment typo 21 November 2017, 05:05:32 UTC
5a80d1d Junio C Hamano 21 November 2017, 05:05:31 UTC Merge branch 'jk/info-alternates-fix' into maint We used to add an empty alternate object database to the system that does not help anything; it has been corrected. * jk/info-alternates-fix: link_alt_odb_entries: make empty input a noop 21 November 2017, 05:05:31 UTC
8e3e51a Junio C Hamano 21 November 2017, 05:05:30 UTC Merge branch 'ab/pcre-v2' into maint Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed. * ab/pcre-v2: grep: fix NO_LIBPCRE1_JIT to fully disable JIT 21 November 2017, 05:05:30 UTC
b77b96e Junio C Hamano 21 November 2017, 05:05:29 UTC Merge branch 'sr/wrapper-quote-filenames' into maint Some error messages did not quote filenames shown in it, which have been fixed. * sr/wrapper-quote-filenames: wrapper.c: consistently quote filenames in error messages 21 November 2017, 05:05:29 UTC
6baa11d Junio C Hamano 21 November 2017, 05:05:29 UTC Merge branch 'bw/rebase-i-ignored-submodule-fix' into maint "git rebase -i" recently started misbehaving when a submodule that is configured with 'submodule.<name>.ignore' is dirty; this has been corrected. * bw/rebase-i-ignored-submodule-fix: wt-status: actually ignore submodules when requested 21 November 2017, 05:05:29 UTC
ffb4568 Shuyu Wei 19 November 2017, 11:01:32 UTC pull: pass -4/-6 option to 'git fetch' The -4/-6 option should be passed through to 'git fetch' to be consistent with the man page. Signed-off-by: Wei Shuyu <wsy@dogben.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 November 2017, 00:53:48 UTC
782c030 René Scharfe 18 November 2017, 10:20:04 UTC config: flip return value of write_section() d9bd4cbb9cc (config: flip return value of store_write_*()) made write_section() follow the convention of write(2) to return -1 on error and the number of written bytes on success. 3b48045c6c7 (Merge branch 'sd/branch-copy') changed it back to returning 0 on error and 1 on success, but left its callers still checking for negative values. Let write_section() follow the convention of write(2) again to meet the expectations of its callers. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 November 2017, 11:38:40 UTC
ae3b2b0 Eric Wong 18 November 2017, 01:01:16 UTC rebase: use mboxrd format to avoid split errors The mboxrd format allows the use of embedded "From " lines in commit messages without being misinterpreted by mailsplit Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 November 2017, 03:30:16 UTC
4855de1 René Scharfe 16 November 2017, 18:50:31 UTC apply: update line lengths for --inaccurate-eof Some diff implementations don't report missing newlines at the end of files. Applying such a patch can cause a newline character to be added inadvertently. The option --inaccurate-eof of git apply can be used to remove trailing newlines if needed. apply_one_fragment() cuts it off from the buffers for preimage and postimage. Before it does, it builds an array with the lengths of each line for both. Make sure to update the length of the last line in these line info structures as well to keep them consistent with their respective buffer. Without this fix the added test fails; git apply dies and reports: fatal: BUG: caller miscounted postlen: asked 1, orig = 1, used = 2 That sanity check is only called if whitespace changes are ignored. Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 November 2017, 01:42:08 UTC
41ca0f7 Todd Zullinger 16 November 2017, 17:09:06 UTC completion: add '--copy' option to 'git branch' In 52d59cc645 (branch: add a --copy (-c) option to go with --move (-m), 2017-06-18), `git branch` learned a `--copy` option. Include it when providing command completions. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 November 2017, 01:32:19 UTC
bd58886 Phillip Wood 15 November 2017, 10:41:25 UTC sequencer: reschedule pick if index can't be locked If the index cannot be locked in do_recursive_merge(), issue an error message and go on to the error recovery codepath, instead of dying. When the commit cannot be picked, it needs to be rescheduled when performing an interactive rebase, but just dying there won't allow that to happen, and when the user runs 'git rebase --continue' rather than 'git rebase --abort', the commit gets silently dropped. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> 16 November 2017, 05:19:12 UTC
c5e3bc6 Phillip Wood 15 November 2017, 12:40:43 UTC config: avoid "write_in_full(fd, buf, len) != len" pattern As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len) != len" pattern, 2017–09–13) the return value of write_in_full() is either -1 or the requested number of bytes. As such comparing the return value to an unsigned value such as strbuf.len will fail to catch errors. Change the code to use the preferred '< 0' check. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 November 2017, 01:36:16 UTC
c641ca6 Elijah Newren 14 November 2017, 17:31:24 UTC merge-recursive: handle addition of submodule on our side of history The code for a newly added path assumed that the path was a normal file, and thus checked for there being a directory still being in the way of the file. Note that since unpack_trees() does path-in-the-way checks already, the only way for there to be a directory in the way at this point in the code, is if there is some kind of D/F conflict in the merge. For a submodule addition on HEAD's side of history, the submodule would have already been present. This means that we do expect there to be a directory present but should not consider it to be "in the way"; instead, it's the expected submodule. So, when there's a submodule addition from HEAD's side, don't bother checking the working copy for a directory in the way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 November 2017, 03:42:34 UTC
back to top