11092ef2b1
In commits 74d5f2397f9abe4834bf1fe1fa02fd6c141b77ce and 10c4ffc6b888eee8f2134a7009a0db1bc393e17b the t/t-path.sh tests were added to validate the remediations of the security issues from CVE-2020-27955 and CVE-2021-21237, respectively. On Windows, both of these tests make use of a "git.bat" script which stands in for Git, and if the script is executed instead of the real Git during a test, then that indicates that a security problem still exists. However, in a previous commit we have now added a new helper program, lfstest-badpathcheck, which can be used for the same purpose, and which has the advantage of having a .exe extension on Windows. We will make use of this helper program in a new test accompanying the remediation of CVE-2022-24826. The existence of this new helper also means we can now use it as a fake "malicious" binary named "git.exe" in our existing t/t-path.sh tests. This will help ensure that these tests are robust against unexpected values of the Windows PATHEXT environment variable or future changes to the set of executable file extensions we support in Git LFS. Using this new helper program instead of a "git.bat" script does mean we need to be careful how and when it might run, because it mirrors the name of the real Git executable. We therefore try to keep it out of any possible execution path until we run our final concluding checks in each test. In other words, rather than try to manipulate PATH (and PATHEXT on Windows), we take steps to keep our "malicious" executable out of any possible search path prior to when we want to explicitly test Git LFS's behaviour in a known state relating to one of the CVEs. (One challenge with manipulating PATH to try to remove paths that resolve to the current directory is that it must be done iteratively to deal with pathological cases like ":.:.:" and ":::". The "sed" regular expressions in our existing tests would also need to use "\." to match only the "." character, as well as additional expressions to match "." at the beginning and end of PATH.) It is easier, therefore, to simply avoid putting our "malicious" executable into the current directory until the last moment. Also, in the second test where we want to add it to a repository which we will then clone, we can remove it as soon as we've run "git add", and we can make sure to run the real Git (i.e., whatever is found first using the extant PATH and PATHEXT variables) rather than ours to perform that "git add". When we reach the end of each test, where we want to explicitly run Git LFS and see if it incorrectly searches in the current directory even when not asked to, we now reset PATH and PATHEXT just for those specific invocations of Git LFS. For PATH we use either BINPATH, which contains only our compiled "git-lfs" binary, or BINPATH plus the path to the real Git as returned by "command -v". For PATHEXT we just use the primary executable file extension (if any) for the current operating system. To determine that primary executable file extension we add an X variable which we set in t/testenv.sh and which parallels the one set in the main Makefile. On Windows, we set X to contain ".exe", and on Unix we set it to the empty string. We can then use this X variable throughout our tests wherever we want to refer to a specific executable's full filename. With these changes, even when PATH includes "." as the first directory to be searched, both of our tests should now always reach their concluding checks and should function as expected at that point. Specifically, they should fail by detecting the output of our "malicious" Git program when run without the Git LFS code changes corresponding to their respective CVEs, and should succeed otherwise. (Technically, the second test will fail for a different reason if the remediation for CVE-2020-27955 is not in effect than if only the remediation for CVE-2021-21237 is not in effect. But the test will fail at the same point in both cases, i.e., in its concluding final check.) In the final checks in both tests we search for the text string "exploit" in the output log file captured after running a Git LFS command, using the shell command "! grep -q 'exploit' output.log". The "!" reverses the exit code from "grep", so if the word "exploit" is found, the test should fail. This works in the first test because the command is the last one in the test, so the inverted exit code from "grep" is returned as the exit code from whole test's subshell. However, in the second test several other commands follow this command, and because "set -e" (which is standard at the top of every test) ignores commands' exit codes when they are inverted with "!", the test proceeds even if the word "exploit" is seen in the output log. To resolve this problem we instead use a command pipeline and ensure that when the "grep" succeeds, the exit code from the final command in the pipeline is generated by "false". This successfully causes the test to fail immediately when the word "exploit" is seen in the output log file. Moreover, in both tests we now follow the "grep" check with checks for the presence of a file named "exploit"; this provides a second level of assurance that our "malicious" Git program has not executed. Finally, we add detailed comments regarding specific steps in both tests where the intention and purpose may not be clear just from the context. |
||
|---|---|---|
| .github | ||
| commands | ||
| config | ||
| creds | ||
| debian | ||
| docker | ||
| docs | ||
| errors | ||
| filepathfilter | ||
| fs | ||
| git | ||
| lfs | ||
| lfsapi | ||
| lfshttp | ||
| locking | ||
| po | ||
| rpm | ||
| script | ||
| ssh | ||
| subprocess | ||
| t | ||
| tasklog | ||
| tools | ||
| tq | ||
| tr | ||
| vendor | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| CHANGELOG.md | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| git-lfs_windows_arm64.go | ||
| git-lfs_windows.go | ||
| git-lfs.go | ||
| go.mod | ||
| go.sum | ||
| INSTALLING.md | ||
| LICENSE.md | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
| versioninfo.json | ||
Git Large File Storage
Git LFS is a command line extension and specification for managing large files with Git.
The client is written in Go, with pre-compiled binaries available for Mac, Windows, Linux, and FreeBSD. Check out the website for an overview of features.
Getting Started
Downloading
You can install the Git LFS client in several different ways, depending on your setup and preferences.
- Linux users. Debian and RPM packages are available from PackageCloud.
- macOS users. Homebrew bottles are distributed, and can
be installed via
brew install git-lfs. - Windows users. Git LFS is included in the distribution of Git for Windows. Alternatively, you can install a recent version of Git LFS from the Chocolatey package manager.
- Binary packages. In addition, binary packages are available for Linux, macOS, Windows, and FreeBSD.
- Building from source. This repository can also be built from source using the latest version of Go, and the available instructions in our Wiki.
Note that Debian and RPM packages are built for all OSes for amd64 and i386. For arm64, only Debian packages for the latest Debian release are built due to the cost of building in emulation.
Installing
From binary
The binary packages include a script which will:
- Install Git LFS binaries onto the system
$PATH - Run
git lfs installto perform required global configuration changes.
$ ./install.sh
From source
- Ensure you have the latest version of Go, GNU make, and a standard Unix-compatible build environment installed.
- On Windows, install
goversioninfowithgo get github.com/josephspurrier/goversioninfo/cmd/goversioninfo. - Run
make. - Place the
git-lfsbinary, which can be found inbin, on your system’s executable$PATHor equivalent. - Git LFS requires global configuration changes once per-machine. This can be done by running:
$ git lfs install
Verifying releases
Releases are signed with the OpenPGP key of one of the core team members. To get these keys, you can run the following command, which will print them to standard output:
$ curl -L https://api.github.com/repos/git-lfs/git-lfs/tarball/core-gpg-keys | tar -Ozxf -
Once you have the keys, you can download the sha256sums.asc file and verify
the file you want like so:
$ gpg -d sha256sums.asc | grep git-lfs-linux-amd64-v2.10.0.tar.gz | shasum -a 256 -c
Example Usage
To begin using Git LFS within a Git repository that is not already configured for Git LFS, you can indicate which files you would like Git LFS to manage. This can be done by running the following from within a Git repository:
$ git lfs track "*.psd"
(Where *.psd is the pattern of filenames that you wish to track. You can read
more about this pattern syntax
here).
Note: the quotation marks surrounding the pattern are important to prevent the glob pattern from being expanded by the shell.
After any invocation of git-lfs-track(1) or git-lfs-untrack(1), you must
commit changes to your .gitattributes file. This can be done by running:
$ git add .gitattributes
$ git commit -m "track *.psd files using Git LFS"
You can now interact with your Git repository as usual, and Git LFS will take
care of managing your large files. For example, changing a file named my.psd
(tracked above via *.psd):
$ git add my.psd
$ git commit -m "add psd"
Tip: if you have large files already in your repository's history,
git lfs trackwill not track them retroactively. To migrate existing large files in your history to use Git LFS, usegit lfs migrate. For example:$ git lfs migrate import --include="*.psd" --everythingNote that this will rewrite history and change all of the Git object IDs in your repository, just like the export version of this command.
For more information, read
git-lfs-migrate(1).
You can confirm that Git LFS is managing your PSD file:
$ git lfs ls-files
3c2f7aedfb * my.psd
Once you've made your commits, push your files to the Git remote:
$ git push origin main
Uploading LFS objects: 100% (1/1), 810 B, 1.2 KB/s
# ...
To https://github.com/git-lfs/git-lfs-test
67fcf6a..47b2002 main -> main
Note: Git LFS requires at least Git 1.8.2 on Linux or 1.8.5 on macOS.
Uninstalling
If you've decided that Git LFS isn't right for you, you can convert your
repository back to a plain Git repository with git lfs migrate as well. For
example:
$ git lfs migrate export --include="*.psd" --everything
Note that this will rewrite history and change all of the Git object IDs in your repository, just like the import version of this command.
If there's some reason that things aren't working out for you, please let us know in an issue, and we'll definitely try to help or get it fixed.
Limitations
Git LFS maintains a list of currently known limitations, which you can find and edit here.
Git LFS source code utilizes Go modules in its build system, and therefore this
project contains a go.mod file with a defined Go module path. However, we
do not maintain a stable Go language API or ABI, as Git LFS is intended to be
used solely as a compiled binary utility. Please do not import the git-lfs
module into other Go code and do not rely on it as a source code dependency.
Need Help?
You can get help on specific commands directly:
$ git lfs help <subcommand>
The official documentation has command references and specifications for the tool. There's also a FAQ on the wiki which answers some common questions.
If you have a question on how to use Git LFS, aren't sure about something, or are looking for input from others on tips about best practices or use cases, feel free to start a discussion.
You can always open an issue, and one of the Core Team members will respond to you. Please be sure to include:
- The output of
git lfs env, which displays helpful information about your Git repository useful in debugging. - Any failed commands re-run with
GIT_TRACE=1in the environment, which displays additional information pertaining to why a command crashed.
Contributing
See CONTRIBUTING.md for info on working on Git LFS and sending patches. Related projects are listed on the Implementations wiki page.
See also SECURITY.md for info on how to submit reports of security vulnerabilities.
Core Team
These are the humans that form the Git LFS core team, which runs the project.
In alphabetical order:
| @bk2204 | @chrisd8088 | @larsxschneider |
|---|---|---|
 |
 |
 |
| PGP 0223B187 | PGP 088335A9 | PGP A5795889 |
Alumni
These are the humans that have in the past formed the Git LFS core team, or have otherwise contributed a significant amount to the project. Git LFS would not be possible without them.
In alphabetical order:
| @andyneff | @PastelMobileSuit | @rubyist | @sinbad | @technoweenie | @ttaylorr |
|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |