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. |
||
|---|---|---|
| .. | ||
| cmd | ||
| fixtures | ||
| git-lfs-test-server-api | ||
| Makefile | ||
| README.md | ||
| t-alternates.sh | ||
| t-askpass.sh | ||
| t-attributes.sh | ||
| t-batch-error-handling.sh | ||
| t-batch-retries-ratelimit.sh | ||
| t-batch-retries.sh | ||
| t-batch-storage-retries-ratelimit.sh | ||
| t-batch-transfer.sh | ||
| t-batch-unknown-oids.sh | ||
| t-checkout.sh | ||
| t-cherry-pick-commits.sh | ||
| t-chunked-transfer-encoding.sh | ||
| t-clean.sh | ||
| t-clone-deprecated.sh | ||
| t-clone.sh | ||
| t-commit-delete-push.sh | ||
| t-config.sh | ||
| t-content-type.sh | ||
| t-credentials-no-prompt.sh | ||
| t-credentials.sh | ||
| t-custom-transfers.sh | ||
| t-dedup.sh | ||
| t-duplicate-oids.sh | ||
| t-env.sh | ||
| t-expired.sh | ||
| t-ext.sh | ||
| t-extra-header.sh | ||
| t-fetch-include.sh | ||
| t-fetch-paths.sh | ||
| t-fetch-recent.sh | ||
| t-fetch-refspec.sh | ||
| t-fetch.sh | ||
| t-filter-branch.sh | ||
| t-filter-process.sh | ||
| t-fsck.sh | ||
| t-happy-path.sh | ||
| t-install-custom-hooks-path-unsupported.sh | ||
| t-install-custom-hooks-path.sh | ||
| t-install-worktree-unsupported.sh | ||
| t-install-worktree.sh | ||
| t-install.sh | ||
| t-lock.sh | ||
| t-locks.sh | ||
| t-logs.sh | ||
| t-ls-files.sh | ||
| t-malformed-pointers.sh | ||
| t-mergetool.sh | ||
| t-migrate-export.sh | ||
| t-migrate-fixup.sh | ||
| t-migrate-import-no-rewrite.sh | ||
| t-migrate-import.sh | ||
| t-migrate-info.sh | ||
| t-object-authenticated.sh | ||
| t-path.sh | ||
| t-pointer.sh | ||
| t-post-checkout.sh | ||
| t-post-commit.sh | ||
| t-post-merge.sh | ||
| t-pre-push.sh | ||
| t-progress-meter.sh | ||
| t-progress.sh | ||
| t-prune-worktree.sh | ||
| t-prune.sh | ||
| t-pull.sh | ||
| t-push-bad-dns.sh | ||
| t-push-failures-local.sh | ||
| t-push-failures-remote.sh | ||
| t-push-file-with-branch-name.sh | ||
| t-push.sh | ||
| t-reference-clone.sh | ||
| t-repo-format.sh | ||
| t-resume-http-range.sh | ||
| t-resume-tus.sh | ||
| t-smudge.sh | ||
| t-ssh.sh | ||
| t-standalone-file.sh | ||
| t-status.sh | ||
| t-submodule-lfsconfig.sh | ||
| t-submodule-recurse.sh | ||
| t-submodule.sh | ||
| t-tempfile.sh | ||
| t-track-attrs.sh | ||
| t-track-wildcards.sh | ||
| t-track.sh | ||
| t-umask.sh | ||
| t-uninstall-worktree-unsupported.sh | ||
| t-uninstall-worktree.sh | ||
| t-uninstall.sh | ||
| t-unlock.sh | ||
| t-untrack.sh | ||
| t-unusual-filenames.sh | ||
| t-update.sh | ||
| t-upload-redirect.sh | ||
| t-verify.sh | ||
| t-version.sh | ||
| t-worktree.sh | ||
| t-zero-len-file.sh | ||
| testenv.sh | ||
| testhelpers.sh | ||
| testlib.sh | ||
t
This directory contains one of the two types of tests that the Git LFS project
uses to protect against regression. The first, scattered in *_test.go files
throughout the repository are unit tests, and written in Go, designed to
uncover failures at the unit level.
The second kind--and the one contained in this directory--are integration
tests, which are designed to exercise Git LFS in an end-to-end fashion,
running the git, and git-lfs binaries, along with a mock Git server.
You can run all tests in this directory with any of the following:
$ make
$ make test
$ make PROVE_EXTRA_ARGS=-j9 test
Or run a single test (for example, t-checkout.sh) by any of the following:
$ make ./t-checkout.sh
$ make PROVE_EXTRA_ARGS=-v ./t-checkout.sh
$ ./t-checkout.sh
Alternatively, one can run a selection of tests (via explicitly listing them or making use of the built-in shell globbing) by any of the following:
$ make ./t-*.sh
$ make PROVE_EXTRA_ARGS=-j9 ./t-*.sh
$ ./t-*.sh
Test File(s)
There are a few important kinds of files to know about in the t directory:
-
cmd/: contains the source code of binaries that are useful during test time, like the mocked Git server, or the test counting binary. For more about the contents of this directory, see test lifecycle below.The file
t/cmd/testutils.gois automatically linked and included during the build process of each file incmd. -
fixtures/: contains shell scripts that load fixture repositories useful for testing against. -
t-*.sh: file(s) containing zero or more tests, typically related to a similar topic (c.f,.t/t-push.sh,t/t-pull.sh, etc.) -
testenv.sh: loads environment variables useful during tests. This file is sourced bytestlib.sh. -
testhelpers.sh: loads shell functions useful during tests, likesetup_remote_repo, andclone_repo. -
testlib.sh: loads thebegin_test,end_test, and similar functions useful for instantiating a particular test.
Test Lifecycle
When a test is run, the following occurs, in order:
-
Missing test binaries are compiled into the
bindirectory in the repository root. Note: this does not include thegit-lfsbinary, which is re-compiled viascript/boostrap. -
An integration server is started by either (1) the
Makefileor (2) thecmd/lfstest-count-test.goprogram, which keeps track of the number of running tests and starts an integration server any time the number of active tests goes from0to1, and stops the server when it goes fromnto0. -
After sourcing
t/testlib.sh(& loadingt/testenv.sh), each test is run in sequence per file. (In other words, multiple test files can be run in parallel, but the tests in a single file are run in sequence.) -
An individual test will finish, and (if running under
prove) another will be started in its place. Once all tests are done,t/test_countwill go to0, and the test server will be torn down.
Test Environment
There are a few environment variables that you can set to change the test suite behavior:
-
GIT_LFS_TEST_DIR=path- This sets the directory that is used as the current working directory of the tests. By default, this will be in your temp dir. It's recommended that this is set to a directory outside of any Git repository. -
KEEPTRASH=1- This will leave the local repository data in atmpdirectory and the remote repository data intest/remote.
Also ensure that your noproxy environment variable contains 127.0.0.1 host,
to allow git commands to reach the local Git server lfstest-gitserver.
Writing new tests
A new test file should be named t/t-*.sh, where * is the topic of Git LFS
being tested. It should look as follows:
#!/usr/bin/env bash
. "$(dirname "$0")/testlib.sh"
begin_test "my test"
(
set -e
# ...
)
end_test