kmx git

Commit	Date	Message
90df4302	2022-01-05T12:18:05	Fix typos
fc42c28e	2021-11-19T09:36:03	util: don't include unnecessary system libraries Remove some unnecessary includes from utility code.
ca14942e	2021-11-11T13:28:08	tests: declare functions statically where appropriate
1728e27c	2021-11-01T18:19:56	path: length validation respecting core.longpaths Teach `git_path_is_valid` to respect `core.longpaths`. Add helper methods to validate length and set the error message appropriately.
315a43b2	2021-11-01T17:37:06	path: introduce `git_path_str_is_valid` Add a `git_str` based validity check; the existing `git_path_is_valid` defers to it.
dd748dbe	2021-11-01T13:04:40	fs_path: make empty component validation optional
bef02d3e	2021-11-01T10:57:28	fs_path: introduce `str_is_valid` Provide a mechanism for users to limit the number of characters that are examined; `git_fs_path_str_is_valid` and friends will only examine up to `str->size` bytes. `git_fs_path_is_valid` delegates to these new functions by passing `SIZE_MAX` (instead of doing a `strlen`), which is a sentinel value meaning "look for a NUL terminator".
63e36c53	2021-11-01T09:34:32	path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".
434a4610	2021-11-01T09:31:32	fs_path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".
95117d47	2021-10-31T09:45:46	path: separate git-specific path functions from util Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
f0e693b1	2021-09-07T17:53:49	str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
4bd17208	2021-05-06T02:28:14	Merge pull request #5858 from libgit2/ethomson/memleaks test: clean up memory leaks
b31795ef	2021-05-06T01:46:19	test: clean up memory leaks
69c65b9a	2019-12-31T12:38:03	path: bump most Win32 unicode buffer sizes from MAX_PATH to GIT_PATH_MAX
dc1ba018	2021-03-20T13:01:00	path: introduce ondisk and workdir path validation Introduce `git_path_validate_filesystem` which validates (absolute) on-disk paths and `git_path_validate_workdir` to perform validations on (absolute) working directory paths. These functions are useful as there may be system limitations on on-disk paths, particularly on Windows (for example, enforcing MAX_PATH). For working directory paths, these limitations may be per-repository, based on the `core.longpaths` configuration setting.
88323cd0	2021-03-20T09:52:17	path: git_path_isvalid -> git_path_validate If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.
f2b114ba	2020-03-08T18:11:45	win32: introduce relative path handling function Add a function that takes a (possibly) relative UTF-8 path and emits a UTF-16 path with forward slashes translated to backslashes. If the given path is, in fact, absolute, it will be translated to absolute path handling rules.
fb7da154	2020-03-08T16:34:23	win32: clarify usage of path canonicalization funcs The path canonicalization functions on win32 are intended to canonicalize absolute paths; those with prefixes. In other words, things start with drive letters (`C:\`), share names (`\\server\share`), or other prefixes (`\\?\`). This function removes leading `..` that occur after the prefix but before the directory/file portion (eg, turning `C:\..\..\..\foo` into `C:\foo`). This translation is not appropriate for local paths.
14ff3516	2019-12-03T23:15:47	path: support non-ascii drive letters on dos Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.
e1832eb2	2019-09-18T16:33:18	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>
f7c6795f	2019-06-07T10:20:35	path: only treat paths starting with '\' as absolute on Win32 Windows-based systems treat paths starting with '\' as absolute, either referring to the current drive's root (e.g. "\foo" might refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On the other hand, (most?) systems that are not based on Win32 accept backslashes as valid characters that may be part of the filename, and thus we cannot treat them to identify absolute paths. Change the logic to only paths starting with '\' as absolute on the Win32 platform. Add tests to avoid regressions and document behaviour.
b5e8272f	2019-01-06T08:29:56	Attempt at fixing the MingW64 compilation It seems like MingW64's size_t is defined differently than in Linux.
bbf9f5a7	2018-11-21T11:20:14	tests: path: only compile test_canonicalize on Win32 platforms The function `test_canonicalize` is only used on Win32 platforms. It will thus result in an unused function warning if these warnings are enabled and one is on a platform different than Win32. Fix the issue by only compiling in the function on Win32 platforms.
16fd9ba9	2018-10-17T11:34:38	win32: more tests for `git_win32_remove_path`
b2e85f98	2018-10-17T08:48:43	win32: rename `git_win32__canonicalize_path` The internal API `git_win32__canonicalize_path` is far, far too easily confused with the internal API `git_win32_path_canonicalize`. The former removes the namespace prefix from a path (eg, given `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given `\\?\UNC\server\share`, it returns `\\server\share`). As such, rename it to `git_win32_path_remove_namespace`. `git_win32_path_canonicalize` remains unchanged.
3f096ca5	2018-10-04T13:03:25	Fix comment style and update test code
8ab11dd5	2018-09-30T16:40:22	Fix issue with path canonicalization for Win32 paths
3be73011	2018-06-11T18:26:22	Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`
ecf4f33a	2018-02-08T11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
92159bd4	2018-05-30T12:18:04	path: unify `git_path_is_*` APIs Right now, there's quite a lot of different function calls to determine whether a path component matches a specific name after normalization from the filesystem. We have a function for each of {gitattributes, gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks. In the long time, this is unmaintainable in case there are e.g. new filesystems with specific semantics, blowing up the number of functions we need to implement. Replace all functions with a simple `git_path_is_gitfile` function, which accepts an enum pointing out the filename that is to be checked against as well as the filesystem normalizations to check for. This greatly simplifies implementation at the expense of the caller having to invoke a somewhat longer function call.
57e343d7	2018-05-24T21:58:40	path: hand-code the zero-width joiner as UTF-8
a7168b47	2018-05-22T16:13:47	path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
02c80ad7	2018-05-22T15:21:08	path: accept the name length as a parameter We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.
177dcfc7	2018-05-18T15:16:53	path: hide the dotgit file functions These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.
9de97ae7	2018-05-16T15:42:08	path: add a function to detect an .gitmodules file Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.
318b825e	2016-02-16T17:11:46	index: allow read of index w/ illegal entries Allow `git_index_read` to handle reading existing indexes with illegal entries. Allow the low-level `git_index_add` to add properly formed `git_index_entry`s even if they contain paths that would be illegal for the current filesystem (eg, `AUX`). Continue to disallow `git_index_add_bypath` from adding entries that are illegal universally illegal (eg, `.git`, `foo/../bar`).
07c989e9	2015-02-03T20:01:24	win32: further cleanups for 8.3 disabling
5f28ec84	2015-02-03T12:16:11	win32: cleanup 8.3 disabled tests
9dcc4a36	2015-01-28T23:04:50	Fix test failures when 8.3 is disabled
1fbfcdfc	2015-01-12T15:48:53	git_path_join_unrooted: return base len The documentation for `git_path_join_unrooted` states that the base length will be returned, so that consumers like checkout know where to start creating directories instead of always creating directories at the directory root.
6987a580	2014-12-19T23:54:42	Add more Windows reserved filenames
6fd00266	2014-12-19T23:54:01	COM0 is a valid path, although Windows Explorer does not allow to create this
ec74b40c	2014-12-16T18:53:55	Introduce core.protectHFS and core.protectNTFS Validate HFS ignored char ".git" paths when `core.protectHFS` is specified. Validate NTFS invalid ".git" paths when `core.protectNTFS` is specified.
11d67b75	2014-12-10T19:12:16	checkout: disallow bad paths on HFS HFS filesystems ignore some characters like U+200C. When these characters are included in a path, they will be ignored for the purposes of comparison with other paths. Thus, if you have a ".git" folder, a folder of ".git<U+200C>" will also match. Protect our ".git" folder by ensuring that ".git<U+200C>" and friends do not match it.
a64119e3	2014-11-25T18:13:00	checkout: disallow bad paths on win32 Disallow: 1. paths with trailing dot 2. paths with trailing space 3. paths with trailing colon 4. paths that are 8.3 short names of .git folders ("GIT~1") 5. paths that are reserved path names (COM1, LPT1, etc). 6. paths with reserved DOS characters (colons, asterisks, etc) These paths would (without \\?\ syntax) be elided to other paths - for example, ".git." would be written as ".git". As a result, writing these paths literally (using \\?\ syntax) makes them hard to operate with from the shell, Windows Explorer or other tools. Disallow these.
cceae9a2	2014-12-01T13:09:58	win32: use NT-prefixed "\\?\" paths When turning UTF-8 paths into UCS-2 paths for Windows, always use the \\?\-prefixed paths. Because this bypasses the system's path canonicalization, handle the canonicalization functions ourselves. We must: 1. always use a backslash as a directory separator 2. only use a single backslash between directories 3. not rely on the system to translate "." and ".." in paths 4. remove trailing backslashes, except at the drive root (C:\)
bbb988a5	2014-09-17T14:52:31	path: Fix `git_path_walk_up` to work with non-rooted paths
1d20092c	2014-09-16T18:36:49	Remove unused buf variable from path/core test.
ccd8ba9b	2014-09-08T16:45:57	Fix warnings in thread-utils.h when building without -DTHREADSAFE=ON The compiler was generating a bunch of warnings for git_mutex_init and git_mutex_lock when GIT_THREADS was not defined (i.e. when not using -DTHREADSAFE=ON). Also remove an unused variable from tests/path/core.c.
0ee9f31c	2014-08-20T10:23:39	Introduce git_path_make_relative

90df4302

2022-01-05T12:18:05

Fix typos

fc42c28e

2021-11-19T09:36:03

util: don't include unnecessary system libraries Remove some unnecessary includes from utility code.

ca14942e

2021-11-11T13:28:08

tests: declare functions statically where appropriate

1728e27c

2021-11-01T18:19:56

path: length validation respecting core.longpaths Teach `git_path_is_valid` to respect `core.longpaths`. Add helper methods to validate length and set the error message appropriately.

315a43b2

2021-11-01T17:37:06

path: introduce `git_path_str_is_valid` Add a `git_str` based validity check; the existing `git_path_is_valid` defers to it.

dd748dbe

2021-11-01T13:04:40

fs_path: make empty component validation optional

bef02d3e

2021-11-01T10:57:28

fs_path: introduce `str_is_valid` Provide a mechanism for users to limit the number of characters that are examined; `git_fs_path_str_is_valid` and friends will only examine up to `str->size` bytes. `git_fs_path_is_valid` delegates to these new functions by passing `SIZE_MAX` (instead of doing a `strlen`), which is a sentinel value meaning "look for a NUL terminator".

63e36c53

2021-11-01T09:34:32

path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".

434a4610

2021-11-01T09:31:32

fs_path: `validate` -> `is_valid` Since we're returning a boolean about validation, the name is more properly "is valid".

95117d47

2021-10-31T09:45:46

path: separate git-specific path functions from util Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).

f0e693b1

2021-09-07T17:53:49

str: introduce `git_str` for internal, `git_buf` is external libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.

4bd17208

2021-05-06T02:28:14

Merge pull request #5858 from libgit2/ethomson/memleaks test: clean up memory leaks

b31795ef

2021-05-06T01:46:19

test: clean up memory leaks

69c65b9a

2019-12-31T12:38:03

path: bump most Win32 unicode buffer sizes from MAX_PATH to GIT_PATH_MAX

dc1ba018

2021-03-20T13:01:00

path: introduce ondisk and workdir path validation Introduce `git_path_validate_filesystem` which validates (absolute) on-disk paths and `git_path_validate_workdir` to perform validations on (absolute) working directory paths. These functions are useful as there may be system limitations on on-disk paths, particularly on Windows (for example, enforcing MAX_PATH). For working directory paths, these limitations may be per-repository, based on the `core.longpaths` configuration setting.

88323cd0

2021-03-20T09:52:17

path: git_path_isvalid -> git_path_validate If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.

f2b114ba

2020-03-08T18:11:45

win32: introduce relative path handling function Add a function that takes a (possibly) relative UTF-8 path and emits a UTF-16 path with forward slashes translated to backslashes. If the given path is, in fact, absolute, it will be translated to absolute path handling rules.

fb7da154

2020-03-08T16:34:23

win32: clarify usage of path canonicalization funcs The path canonicalization functions on win32 are intended to canonicalize absolute paths; those with prefixes. In other words, things start with drive letters (`C:\`), share names (`\\server\share`), or other prefixes (`\\?\`). This function removes leading `..` that occur after the prefix but before the directory/file portion (eg, turning `C:\..\..\..\foo` into `C:\foo`). This translation is not appropriate for local paths.

14ff3516

2019-12-03T23:15:47

path: support non-ascii drive letters on dos Windows/DOS only supports drive letters that are alpha characters A-Z. However, you can `subst` any one-character as a drive letter, including numbers or even emoji. Test that we can identify emoji as drive letters.

e1832eb2

2019-09-18T16:33:18

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>

f7c6795f

2019-06-07T10:20:35

path: only treat paths starting with '\' as absolute on Win32 Windows-based systems treat paths starting with '\' as absolute, either referring to the current drive's root (e.g. "\foo" might refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On the other hand, (most?) systems that are not based on Win32 accept backslashes as valid characters that may be part of the filename, and thus we cannot treat them to identify absolute paths. Change the logic to only paths starting with '\' as absolute on the Win32 platform. Add tests to avoid regressions and document behaviour.

b5e8272f

2019-01-06T08:29:56

Attempt at fixing the MingW64 compilation It seems like MingW64's size_t is defined differently than in Linux.

bbf9f5a7

2018-11-21T11:20:14

tests: path: only compile test_canonicalize on Win32 platforms The function `test_canonicalize` is only used on Win32 platforms. It will thus result in an unused function warning if these warnings are enabled and one is on a platform different than Win32. Fix the issue by only compiling in the function on Win32 platforms.

16fd9ba9

2018-10-17T11:34:38

win32: more tests for `git_win32_remove_path`

b2e85f98

2018-10-17T08:48:43

win32: rename `git_win32__canonicalize_path` The internal API `git_win32__canonicalize_path` is far, far too easily confused with the internal API `git_win32_path_canonicalize`. The former removes the namespace prefix from a path (eg, given `\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given `\\?\UNC\server\share`, it returns `\\server\share`). As such, rename it to `git_win32_path_remove_namespace`. `git_win32_path_canonicalize` remains unchanged.

3f096ca5

2018-10-04T13:03:25

Fix comment style and update test code

8ab11dd5

2018-09-30T16:40:22

Fix issue with path canonicalization for Win32 paths

3be73011

2018-06-11T18:26:22

Merge pull request #4436 from pks-t/pks/packfile-stream-free pack: rename `git_packfile_stream_free`

ecf4f33a

2018-02-08T11:14:48

Convert usage of `git_buf_free` to new `git_buf_dispose`

92159bd4

2018-05-30T12:18:04

path: unify `git_path_is_*` APIs Right now, there's quite a lot of different function calls to determine whether a path component matches a specific name after normalization from the filesystem. We have a function for each of {gitattributes, gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks. In the long time, this is unmaintainable in case there are e.g. new filesystems with specific semantics, blowing up the number of functions we need to implement. Replace all functions with a simple `git_path_is_gitfile` function, which accepts an enum pointing out the filename that is to be checked against as well as the filesystem normalizations to check for. This greatly simplifies implementation at the expense of the caller having to invoke a somewhat longer function call.

57e343d7

2018-05-24T21:58:40

path: hand-code the zero-width joiner as UTF-8

a7168b47

2018-05-22T16:13:47

path: reject .gitmodules as a symlink Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.

02c80ad7

2018-05-22T15:21:08

path: accept the name length as a parameter We may take in names from the middle of a string so we want the caller to let us know how long the path component is that we should be checking.

177dcfc7

2018-05-18T15:16:53

path: hide the dotgit file functions These can't go into the public API yet as we don't want to introduce API or ABI changes in a security release.

9de97ae7

2018-05-16T15:42:08

path: add a function to detect an .gitmodules file Given a path component it knows what to pass to the filesystem-specific functions so we're protected even from trees which try to use the 8.3 naming rules to get around us matching on the filename exactly. The logic and test strings come from the equivalent git change.

318b825e

2016-02-16T17:11:46

index: allow read of index w/ illegal entries Allow `git_index_read` to handle reading existing indexes with illegal entries. Allow the low-level `git_index_add` to add properly formed `git_index_entry`s even if they contain paths that would be illegal for the current filesystem (eg, `AUX`). Continue to disallow `git_index_add_bypath` from adding entries that are illegal universally illegal (eg, `.git`, `foo/../bar`).

07c989e9

2015-02-03T20:01:24

win32: further cleanups for 8.3 disabling

5f28ec84

2015-02-03T12:16:11

win32: cleanup 8.3 disabled tests

9dcc4a36

2015-01-28T23:04:50

Fix test failures when 8.3 is disabled

1fbfcdfc

2015-01-12T15:48:53

git_path_join_unrooted: return base len The documentation for `git_path_join_unrooted` states that the base length will be returned, so that consumers like checkout know where to start creating directories instead of always creating directories at the directory root.

6987a580

2014-12-19T23:54:42

Add more Windows reserved filenames

6fd00266

2014-12-19T23:54:01

COM0 is a valid path, although Windows Explorer does not allow to create this

ec74b40c

2014-12-16T18:53:55

Introduce core.protectHFS and core.protectNTFS Validate HFS ignored char ".git" paths when `core.protectHFS` is specified. Validate NTFS invalid ".git" paths when `core.protectNTFS` is specified.

11d67b75

2014-12-10T19:12:16

checkout: disallow bad paths on HFS HFS filesystems ignore some characters like U+200C. When these characters are included in a path, they will be ignored for the purposes of comparison with other paths. Thus, if you have a ".git" folder, a folder of ".git<U+200C>" will also match. Protect our ".git" folder by ensuring that ".git<U+200C>" and friends do not match it.

a64119e3

2014-11-25T18:13:00

checkout: disallow bad paths on win32 Disallow: 1. paths with trailing dot 2. paths with trailing space 3. paths with trailing colon 4. paths that are 8.3 short names of .git folders ("GIT~1") 5. paths that are reserved path names (COM1, LPT1, etc). 6. paths with reserved DOS characters (colons, asterisks, etc) These paths would (without \\?\ syntax) be elided to other paths - for example, ".git." would be written as ".git". As a result, writing these paths literally (using \\?\ syntax) makes them hard to operate with from the shell, Windows Explorer or other tools. Disallow these.

cceae9a2

2014-12-01T13:09:58

win32: use NT-prefixed "\\?\" paths When turning UTF-8 paths into UCS-2 paths for Windows, always use the \\?\-prefixed paths. Because this bypasses the system's path canonicalization, handle the canonicalization functions ourselves. We must: 1. always use a backslash as a directory separator 2. only use a single backslash between directories 3. not rely on the system to translate "." and ".." in paths 4. remove trailing backslashes, except at the drive root (C:\)

bbb988a5

2014-09-17T14:52:31

path: Fix `git_path_walk_up` to work with non-rooted paths

1d20092c

2014-09-16T18:36:49

Remove unused buf variable from path/core test.

ccd8ba9b

2014-09-08T16:45:57

Fix warnings in thread-utils.h when building without -DTHREADSAFE=ON The compiler was generating a bunch of warnings for git_mutex_init and git_mutex_lock when GIT_THREADS was not defined (i.e. when not using -DTHREADSAFE=ON). Also remove an unused variable from tests/path/core.c.

0ee9f31c

2014-08-20T10:23:39

Introduce git_path_make_relative

thodg/libgit2/tests/path

tests/path

Log