| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Remove some unnecessary includes from utility code.
|
| | |
|
| |
|
|
|
| |
Teach `git_path_is_valid` to respect `core.longpaths`. Add helper
methods to validate length and set the error message appropriately.
|
| |
|
|
|
| |
Add a `git_str` based validity check; the existing `git_path_is_valid`
defers to it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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".
|
| |
|
|
|
| |
Since we're returning a boolean about validation, the name is more
properly "is valid".
|
| |
|
|
|
| |
Since we're returning a boolean about validation, the name is more
properly "is valid".
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
test: clean up memory leaks
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
It seems like MingW64's size_t is defined differently than in Linux.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| | |
pack: rename `git_packfile_stream_free`
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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`).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Validate HFS ignored char ".git" paths when `core.protectHFS` is
specified. Validate NTFS invalid ".git" paths when `core.protectNTFS`
is specified.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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:\)
|
| | |
|
| |
|
