1. 09 Jun, 2020 1 commit
  2. 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
  3. 24 Aug, 2019 1 commit
  4. 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
  5. 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
  6. 18 Jul, 2019 1 commit
  7. 24 Jun, 2019 1 commit
  8. 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
  9. 22 Jan, 2019 1 commit
  10. 25 Sep, 2018 1 commit
  11. 12 Sep, 2018 1 commit
    • path validation: `char` is not signed by default. · 44291868
      ARM treats its `char` type as `unsigned type` by default; as a result,
      testing a `char` value as being `< 0` is always false.  This is a
      warning on ARM, which is promoted to an error given our use of
      `-Werror`.
      
      Per ISO 9899:199, section "6.2.5 Types":
      
      > The three types char, signed char, and unsigned char are collectively
      > called the character types. The implementation shall define char to
      > have the same range, representation, and behavior as either signed
      > char or unsigned char.
      >
      ...
      
      > Irrespective of the choice made, char is a separate type from the other
      > two and is not compatible with either.
      Edward Thomson committed
  12. 10 Jun, 2018 1 commit
  13. 01 Jun, 2018 1 commit
    • path: unify `git_path_is_*` APIs · 92159bd4
      Right now, there's quite a lot of different function calls to determine
      whether a path component matches a specific name after normalization
      from the filesystem. We have a function for each of {gitattributes,
      gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks.
      In the long time, this is unmaintainable in case there are e.g. new
      filesystems with specific semantics, blowing up the number of functions
      we need to implement.
      
      Replace all functions with a simple `git_path_is_gitfile` function,
      which accepts an enum pointing out the filename that is to be checked
      against as well as the filesystem normalizations to check for. This
      greatly simplifies implementation at the expense of the caller having to
      invoke a somewhat longer function call.
      Patrick Steinhardt committed
  14. 23 May, 2018 2 commits
  15. 22 May, 2018 2 commits
  16. 18 May, 2018 4 commits
  17. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  18. 08 Jun, 2017 1 commit
  19. 04 Apr, 2017 2 commits
  20. 08 Feb, 2017 3 commits
    • path: ensure dirname on Win32 prefix always has a trailing '/' · 9e8d75c7
      When calling `git_path_dirname_r` on a Win32 prefix, e.g. a drive
      or network share prefix, we always want to return the trailing
      '/'. This does not work currently when passing in a path like
      'C:', where the '/' would not be appended correctly.
      
      Fix this by appending a '/' if we try to normalize a Win32 prefix
      and there is no trailing '/'.
      Patrick Steinhardt committed
    • path: get correct dirname for Windows root · 5d59520c
      Getting the dirname of a filesystem root should return the filesystem
      root itself. E.g. the dirname of "/" is always "/". On Windows, we
      emulate this behavior and as such, we should return e.g. "C:/" if
      calling dirname on "C:/". But we currently fail to do so and instead
      return ".", as we do not check if we actually have a Windows prefix
      before stripping off the last directory component.
      
      Fix this by calling out to `win32_prefix_length` immediately after
      stripping trailing slashes, returning early if we have a prefix.
      Patrick Steinhardt committed
    • path: extract `win32_path_prefix` function · d8c06070
      Extract code which determines if a path is at a Windows system's root.
      This incluses drive prefixes (e.g. "C:\") as well as network computer
      names (e.g. "//computername/").
      Patrick Steinhardt committed
  21. 29 Dec, 2016 1 commit
  22. 12 Dec, 2016 1 commit
  23. 14 Nov, 2016 2 commits
  24. 26 May, 2016 1 commit
  25. 24 Mar, 2016 1 commit
  26. 23 Feb, 2016 1 commit
  27. 17 Feb, 2016 1 commit
    • index: allow read of index w/ illegal entries · 318b825e
      Allow `git_index_read` to handle reading existing indexes with
      illegal entries.  Allow the low-level `git_index_add` to add
      properly formed `git_index_entry`s even if they contain paths
      that would be illegal for the current filesystem (eg, `AUX`).
      Continue to disallow `git_index_add_bypath` from adding entries
      that are illegal universally illegal (eg, `.git`, `foo/../bar`).
      Edward Thomson committed