1. 18 Sep, 2020 1 commit
  2. 27 Jun, 2020 1 commit
  3. 21 Jun, 2020 1 commit
    • mwindow: set limit on number of open files · 9679df57
      There are some cases in which repositories accrue a large number of
      packfiles. The existing mwindow limit applies only to the total size of
      mmap'd files, not on their number. This leads to a situation in which
      having lots of small packfiles could exhaust the allowed number of open
      files, particularly on macOS, where the default ulimit is very low
      (256).
      
      This change adds a new configuration parameter
      (GIT_OPT_SET_MWINDOW_FILE_LIMIT) that sets the maximum number of open
      packfiles, with a default of 128. This is low enough so that even macOS
      users should not hit it during normal use.
      
      Based on PR #5386, originally written by @josharian.
      
      Fixes: #2758
      lhchavez committed
  4. 14 Apr, 2020 1 commit
  5. 23 Mar, 2020 1 commit
  6. 15 Jan, 2020 1 commit
    • refs: refuse to delete HEAD · 852c83ee
      This requires adding a new symbolic ref to the testrepo fixture.
      Some of the existing tests attempt to delete HEAD, expecting a different failure. Introduce and use a non-HEAD symbolic ref instead.
      Adjust a few other tests as needed.
      
      Fixes #5357
      Josh Bleecher Snyder committed
  7. 10 Dec, 2019 1 commit
    • Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS · 3f7851ea
      A little-known feature of NTFS is that it offers to store metadata in
      so-called "Alternate Data Streams" (inspired by Apple's "resource
      forks") that are copied together with the file they are associated with.
      These Alternate Data Streams can be accessed via `<file name>:<stream
      name>:<stream type>`.
      
      Directories, too, have Alternate Data Streams, and they even have a
      default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and
      `abc::$INDEX_ALLOCATION/` are actually equivalent.
      
      This is of course another attack vector on the Git directory that we
      definitely want to prevent.
      
      On Windows, we already do this incidentally, by disallowing colons in
      file/directory names.
      
      While it looks as if files'/directories' Alternate Data Streams are not
      accessible in the Windows Subsystem for Linux, and neither via
      CIFS/SMB-mounted network shares in Linux, it _is_ possible to access
      them on SMB-mounted network shares on macOS.
      
      Therefore, let's go the extra mile and prevent this particular attack
      _everywhere_. To keep things simple, let's just disallow *any* Alternate
      Data Stream of `.git`.
      
      This is libgit2's variant of CVE-2019-1352.
      
      Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      Johannes Schindelin committed
  8. 05 Nov, 2019 1 commit
    • config_entries: micro-optimize storage of multivars · b7dcea04
      Multivars are configuration entries that have many values for the same
      name; we can thus micro-optimize this case by just retaining the name of
      the first configuration entry and freeing all the others, letting them
      point to the string of the first entry.
      
      The attached test case is an extreme example that demonstrates this. It
      contains a section name that is approximately 500kB in size with 20.000
      entries "a=b". Without the optimization, this would require at least
      20000*500kB bytes, which is around 10GB. With this patch, it only
      requires 500kB+20000*1B=20500kB.
      
      The obvious culprit here is the section header, which we repeatedly
      include in each of the configuration entry's names. This makes it very
      easier for an adversary to provide a small configuration file that
      disproportionally blows up in memory during processing and is thus a
      feasible way for a denial-of-service attack. Unfortunately, we cannot
      fix the root cause by e.g. having a separate "section" field that may
      easily be deduplicated due to the `git_config_entry` structure being
      part of our public API. So this micro-optimization is the best we can do
      for now.
      Patrick Steinhardt committed
  9. 21 Aug, 2019 1 commit
    • smart: use push_glob instead of manual filtering · 39d18fe6
      The code worked under the assumption that anything under `refs/tags` are
      tag objects, and all the rest would be peelable to a commit. As it is
      completely valid to have tags to blobs under a non `refs/tags` ref, this
      would cause failures when trying to peel a tag to a commit.
      
      Fix the broken filtering by switching to `git_revwalk_push_glob`, which
      already handles this case.
      Etienne Samson committed
  10. 11 Aug, 2019 2 commits
  11. 10 Jun, 2019 2 commits
  12. 24 May, 2019 1 commit
  13. 24 Jan, 2019 1 commit
    • index: preserve extension parsing errors · 0bf7e043
      Previously, we would clobber any extension-specific error message with
      an "extension is truncated" message. This makes `read_extension`
      correctly preserve those errors, takes responsibility for truncation
      errors, and adds a new message with the actual extension signature for
      unsupported mandatory extensions.
      Etienne Samson committed
  14. 15 Jan, 2019 1 commit
  15. 14 Jan, 2019 1 commit
  16. 04 Dec, 2018 3 commits
  17. 03 Dec, 2018 1 commit
    • crlf_data: move to a "to_workdir" folder · 13a8bc92
      Move the crlf_data folders reponsible for holding the state of the
      filters going into the working directory to "to_workdir" variations of
      the folder name to accommodate future growth into the "to odb" filter
      variation.  Update the script to create these new folders as appopriate.
      Edward Thomson committed
  18. 05 Nov, 2018 1 commit
  19. 20 Oct, 2018 1 commit
    • checkout: fix test fixture missing objects · c79e6081
      The testrepo test fixture has an index file that's damaged, missing an
      object.  The index previously had an entry of `src/index.c` with id
      3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in
      the repository.  This commit adds an object to the repository and
      updates the index to use that existing blob.
      
      Similarly, the index has an entry for `readme` with an id of
      97328ac7e3bd0bcd3900cb3e7a624d71dd0df888.  This can be restored from
      other test repositories.
      
      With these fixed, now the write tree from index tests can pass since they
      validate object existence.
      Edward Thomson committed
  20. 04 Oct, 2018 1 commit
    • tests: verify diff stats with renames in subdirectory · 3148efd2
      Until now, we didn't have any tests that verified that our format for
      renames in subdirectories is correct. While our current behaviour is no
      different than for renames that do not happen with a common prefix
      shared between old and new file name, we intend to change the format to
      instead match the format that upstream git uses.
      
      Add a test case for this to document our current behaviour and to show
      how the next commit will change that format.
      Patrick Steinhardt committed
  21. 14 Aug, 2018 1 commit
  22. 18 Jul, 2018 1 commit
    • tree: accept null ids in existing trees when updating · 2dff7e28
      When we add entries to a treebuilder we validate them. But we validate even
      those that we're adding because they exist in the base tree. This disables
      using the normal mechanisms on these trees, even to fix them.
      
      Keep track of whether the entry we're appending comes from an existing tree and
      bypass the name and id validation if it's from existing data.
      Carlos Martín Nieto committed
  23. 15 Jun, 2018 3 commits
  24. 22 May, 2018 1 commit
  25. 17 Apr, 2018 3 commits
  26. 12 Apr, 2018 1 commit
    • revwalk: fix uninteresting revs sometimes not limiting graphwalk · 54fd80e3
      When we want to limit our graphwalk, we use the heuristic of checking
      whether the newest limiting (uninteresting) revision is newer than the
      oldest interesting revision. We do so by inspecting whether the first
      item's commit time of the user-supplied list of revisions is newer than
      the last added interesting revision. This is wrong though, as the user
      supplied list is in no way guaranteed to be sorted by increasing commit
      dates. This could lead us to abort the revwalk early before applying all
      relevant limiting revisions, outputting revisions which should in fact
      have been hidden.
      
      Fix the heuristic by instead checking whether _any_ of the limiting
      commits was made earlier than the last interesting commit. Add a test.
      Patrick Steinhardt committed
  27. 24 Feb, 2018 1 commit
  28. 20 Feb, 2018 1 commit
  29. 04 Feb, 2018 2 commits
  30. 04 Dec, 2017 1 commit
  31. 25 Aug, 2017 1 commit
    • submodule: refuse lookup in bare repositories · 477b3e04
      While it is technically possible to look up submodules inside of a
      bare repository by reading the submodule configuration of a specific
      commit, we do not offer this functionality right now. As such, calling
      both `git_submodule_lookup` and `git_submodule_foreach` should error out
      early when these functions encounter a bare repository. While
      `git_submodule_lookup` already does return an error due to not being
      able to parse the configuration, `git_submodule_foreach` simply returns
      success and never invokes the callback function.
      
      Fix the issue by having both functions check whether the repository is
      bare and returning an error in that case.
      Patrick Steinhardt committed