1. 12 Apr, 2022 1 commit
  2. 11 Apr, 2022 1 commit
  3. 27 Feb, 2022 1 commit
  4. 23 Feb, 2022 2 commits
  5. 09 Feb, 2022 1 commit
  6. 18 Jan, 2022 1 commit
  7. 05 Jan, 2022 1 commit
  8. 09 Nov, 2021 8 commits
  9. 17 Oct, 2021 1 commit
    • str: introduce `git_str` for internal, `git_buf` is external · f0e693b1
      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.
      Edward Thomson committed
  10. 09 Sep, 2021 1 commit
  11. 09 Aug, 2021 1 commit
  12. 28 Apr, 2021 3 commits
    • path: don't join paths in git_path_find_dir · 1016ad4f
      Let `git_path_find_dir` simply take a `git_buf` that contains a
      directory or a file, instead of trying to both join a path AND then deal
      with prettifying it or its basename.  This allows consumers to join
      paths themselves (and apply any necessary rules - like fitting within
      MAX_PATH).
      Edward Thomson committed
    • apply: ensure we validate paths · dbc03de4
      There was no test ensuring that we validate `.git` paths.  We do, but
      let's add a test to make sure that we never regress this.
      Edward Thomson committed
    • path: introduce ondisk and workdir path validation · dc1ba018
      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.
      Edward Thomson committed
  13. 14 Apr, 2021 2 commits
    • path: git_path_isvalid -> git_path_validate · 88323cd0
      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.
      Edward Thomson committed
    • utf8: refactor utf8 functions · 1d95b59b
      Move the utf8 functions into a proper namespace `git_utf8` instead of
      being in the namespaceless `git__` function group.  Update them to
      have out-params first and use `char *` instead of `uint8_t *` to match
      our API treating strings as `char *` (even if they truly contain `uchar`s
      inside).
      Edward Thomson committed
  14. 27 Nov, 2020 2 commits
  15. 06 Oct, 2020 1 commit
  16. 09 Jun, 2020 1 commit
  17. 10 Dec, 2019 5 commits
    • path: support non-ascii drive letters on dos · 14ff3516
      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.
      Edward Thomson committed
    • path: protect NTFS everywhere · e4034dfa
      Enable core.protectNTFS by default everywhere and in every codepath, not
      just on checkout.
      Edward Thomson committed
    • path: rename function that detects end of filename · b8464342
      The function `only_spaces_and_dots` used to detect the end of the
      filename on win32.  Now we look at spaces and dots _before_ the end of
      the string _or_ a `:` character, which would signify a win32 alternate
      data stream.
      
      Thus, rename the function `ntfs_end_of_filename` to indicate that it
      detects the (virtual) end of a filename, that any further characters
      would be elided to the given path.
      Edward Thomson committed
    • path: also guard `.gitmodules` against NTFS Alternate Data Streams · e1832eb2
      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>
      Johannes Schindelin committed
    • 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
  18. 24 Aug, 2019 1 commit
  19. 13 Aug, 2019 1 commit
    • config: validate ownership of C:\ProgramData\Git\config before using it · cb1439c9
      When the VirtualStore feature is in effect, it is safe to let random
      users write into C:\ProgramData because other users won't see those
      files. This seemed to be the case when we introduced support for
      C:\ProgramData\Git\config.
      
      However, when that feature is not in effect (which seems to be the case
      in newer Windows 10 versions), we'd rather not use those files unless
      they come from a trusted source, such as an administrator.
      
      This change imitates the strategy chosen by PowerShell's native OpenSSH
      port to Windows regarding host key files: if a system file is owned
      neither by an administrator, a system account, or the current user, it
      is ignored.
      Johannes Schindelin committed
  20. 20 Jul, 2019 1 commit
    • path: extract function to check whether a path supports symlinks · ded77bb1
      When initializing a repository, we need to check whether its working
      directory supports symlinks to correctly set the initial value of the
      "core.symlinks" config variable. The code to check the filesystem is
      reusable in other parts of our codebase, like for example in our tests
      to determine whether certain tests can be expected to succeed or not.
      
      Extract the code into a new function `git_path_supports_symlinks` to
      avoid duplicate implementations. Remove a duplicate implementation in
      the repo test helper code.
      Patrick Steinhardt committed
  21. 18 Jul, 2019 1 commit
  22. 24 Jun, 2019 1 commit
  23. 13 Jun, 2019 1 commit
    • path: only treat paths starting with '\' as absolute on Win32 · f7c6795f
      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.
      Patrick Steinhardt committed
  24. 22 Jan, 2019 1 commit