git/attr.h, branch v2.43.2

attr: add attr.tree for setting the treeish to read attributes from

2023-10-13T18:43:29Z

44451a2 (attr: teach "--attr-source=" global option to "git", 2023-05-06) provided the ability to pass in a treeish as the attr source. In the context of serving Git repositories as bare repos like we do at GitLab however, it would be easier to point --attr-source to HEAD for all commands by setting it once. Add a new config attr.tree that allows this. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

attr: expose and rename accessor functions

2023-06-27T18:31:06Z

Right now, the functions which determine the current system and global gitattributes files are not exposed. We'd like to use them in a future commit, but they're not ideally named. Rename them to something more suitable as a public interface, expose them, and document them. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

attr: teach "--attr-source=" global option to "git"

2023-05-06T21:34:09Z

Earlier, 47cfc9bd (attr: add flag `--source` to work with tree-ish, 2023-01-14) taught "git check-attr" the "--source=" option to allow it to read attribute files from a tree-ish, but did so only for the command. Just like "check-attr" users wanted a way to use attributes from a tree-ish and not from the working tree files, users of other commands (like "git diff") would benefit from the same. Undo most of the UI change the commit made, while keeping the internal logic to read attributes from a given tree-ish. Expose the internal logic via a new "--attr-source=" command line option given to "git", so that it can be used with any git command that runs as part of the main git process. Additionally, add an environment variable GIT_ATTR_SOURCE that is set when --attr-source is passed in, so that subprocesses use the same value for the attributes source tree. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

attr: fix instructions on how to check attrs

2023-01-26T22:16:48Z

The instructions in attr.h describing what functions to call to check attributes is missing the index as the first argument to git_check_attr(), as well as tree_oid as the second argument. When 7a400a2c (attr: remove an implicit dependency on the_index, 2018-08-13) started passing an index_state instance to git_check_attr(), it forgot to update the API documentation in Documentation/technical/api-gitattributes.txt. Later, 3a1b3415 (attr: move doc to attr.h, 2019-11-17) moved the API documentation to attr.h as a comment, but still left out the index_state as an argument. In 47cfc9b (attr: add flag `--source` to work with tree-ish 2023-01-14) added tree_oid as an optional parameter but was not added to the docs in attr.h Fix this to make the documentation in the comment consistent with the actual function signature. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

Merge branch 'kn/attr-from-tree'

2023-01-23T21:39:51Z

"git check-attr" learned to take an optional tree-ish to read the .gitattributes file from. * kn/attr-from-tree: attr: add flag `--source` to work with tree-ish t0003: move setup for `--all` into new block

attr: add flag `--source` to work with tree-ish

2023-01-14T16:49:55Z

The contents of the .gitattributes files may evolve over time, but "git check-attr" always checks attributes against them in the working tree and/or in the index. It may be beneficial to optionally allow the users to check attributes taken from a commit other than HEAD against paths. Add a new flag `--source` which will allow users to check the attributes against a commit (actually any tree-ish would do). When the user uses this flag, we go through the stack of .gitattributes files but instead of checking the current working tree and/or in the index, we check the blobs from the provided tree-ish object. This allows the command to also be used in bare repositories. Since we use a tree-ish object, the user can pass "--source HEAD:subdirectory" and all the attributes will be looked up as if subdirectory was the root directory of the repository. We cannot simply use the `:` syntax without the `--source` flag, similar to how it is used in `git show` because any non-flag parameter before `--` is treated as an attribute and any parameter after `--` is treated as a pathname. The change involves creating a new function `read_attr_from_blob`, which given the path reads the blob for the path against the provided source and parses the attributes line by line. This function is plugged into `read_attr()` function wherein we go through the stack of attributes files. Signed-off-by: Karthik Nayak Signed-off-by: Toon Claes Co-authored-by: toon@iotcl.com Signed-off-by: Junio C Hamano

Merge branch 'maint-2.35' into maint-2.36

2022-12-13T12:19:11Z

Sync with Git 2.31.6

2022-12-13T12:09:40Z

attr: ignore overly large gitattributes files

2022-12-05T06:50:03Z

Similar as with the preceding commit, start ignoring gitattributes files that are overly large to protect us against out-of-bounds reads and writes caused by integer overflows. Unfortunately, we cannot just define "overly large" in terms of any preexisting limits in the codebase. Instead, we choose a very conservative limit of 100MB. This is plenty of room for specifying gitattributes, and incidentally it is also the limit for blob sizes for GitHub. While we don't want GitHub to dictate limits here, it is still sensible to use this fact for an informed decision given that it is hosting a huge set of repositories. Furthermore, over at GitLab we scanned a subset of repositories for their root-level attribute files. We found that 80% of them have a gitattributes file smaller than 100kB, 99.99% have one smaller than 1MB, and only a single repository had one that was almost 3MB in size. So enforcing a limit of 100MB seems to give us ample of headroom. With this limit in place we can be reasonably sure that there is no easy way to exploit the gitattributes file via integer overflows anymore. Furthermore, it protects us against resource exhaustion caused by allocating the in-memory data structures required to represent the parsed attributes. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

attr: ignore attribute lines exceeding 2048 bytes

2022-12-05T06:33:07Z

There are two different code paths to read gitattributes: once via a file, and once via the index. These two paths used to behave differently because when reading attributes from a file, we used fgets(3P) with a buffer size of 2kB. Consequentially, we silently truncate line lengths when lines are longer than that and will then parse the remainder of the line as a new pattern. It goes without saying that this is entirely unexpected, but it's even worse that the behaviour depends on how the gitattributes are parsed. While this is simply wrong, the silent truncation saves us with the recently discovered vulnerabilities that can cause out-of-bound writes or reads with unreasonably long lines due to integer overflows. As the common path is to read gitattributes via the worktree file instead of via the index, we can assume that any gitattributes file that had lines longer than that is already broken anyway. So instead of lifting the limit here, we can double down on it to fix the vulnerabilities. Introduce an explicit line length limit of 2kB that is shared across all paths that read attributes and ignore any line that hits this limit while printing a warning. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano