1. 26 Mar, 2018 4 commits
    • config_file: move include depth into config entry · 26cf48fc
      In order to reject writes to included configuration entries, we need to
      keep track of whether an entry was included via another configuration
      file or not. This information is being stored in the `cvar` structure,
      which is a rather weird location, as it is only used to create a list
      structure of config entries.
      
      Move the include depth into the structure `git_config_entry` instead.
      While this fixes the layering issue, it enables users of libgit2 to
      access the depth, too.
      Patrick Steinhardt committed
    • config_file: move cvar handling into `append_entry` · fcb0d841
      The code appending new configuration entries to our current list first
      allocates the `cvar` structure and then passes it to `append_entry`. As
      we want to extend `append_entry` to store configuration entries in a map
      as well as in a list for ordered iteration, we will have to create two
      `cvar` structures, though. As such, the future change will become much
      easier when allocation of the `cvar` structure is doen in `append_entry`
      itself.
      Patrick Steinhardt committed
    • config_file: remove unused list iteration macros · dfcd923c
      We currently provide a lot of macros for the `cvar_t` structure which
      are never being used. In fact, the only macro we need is to access the
      `next` pointer of `cvar_t`, which really does not require a macro at
      all.
      
      Remove all these macros and replace usage of `CVAR_LIST_NEXT(cvar)` with
      `cvar->next`.
      Patrick Steinhardt committed
    • Merge pull request #4570 from newren/master · 7bd129e4
      Add myself to git.git-authors
      Patrick Steinhardt committed
  2. 23 Mar, 2018 3 commits
  3. 20 Mar, 2018 3 commits
  4. 19 Mar, 2018 11 commits
  5. 13 Mar, 2018 1 commit
  6. 12 Mar, 2018 2 commits
  7. 11 Mar, 2018 1 commit
  8. 10 Mar, 2018 3 commits
    • index: error out on unreasonable prefix-compressed path lengths · 3db1af1f
      When computing the complete path length from the encoded
      prefix-compressed path, we end up just allocating the complete path
      without ever checking what the encoded path length actually is. This can
      easily lead to a denial of service by just encoding an unreasonable long
      path name inside of the index. Git already enforces a maximum path
      length of 4096 bytes. As we also have that enforcement ready in some
      places, just make sure that the resulting path is smaller than
      GIT_PATH_MAX.
      
      Reported-by: Krishna Ram Prakash R <krp@gtux.in>
      Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
      Patrick Steinhardt committed
    • index: fix out-of-bounds read with invalid index entry prefix length · 3207ddb0
      The index format in version 4 has prefix-compressed entries, where every
      index entry can compress its path by using a path prefix of the previous
      entry. Since implmenting support for this index format version in commit
      5625d86b (index: support index v4, 2016-05-17), though, we do not
      correctly verify that the prefix length that we want to reuse is
      actually smaller or equal to the amount of characters than the length of
      the previous index entry's path. This can lead to a an integer underflow
      and subsequently to an out-of-bounds read.
      
      Fix this by verifying that the prefix is actually smaller than the
      previous entry's path length.
      
      Reported-by: Krishna Ram Prakash R <krp@gtux.in>
      Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
      Patrick Steinhardt committed
    • index: convert `read_entry` to return entry size via an out-param · 58a6fe94
      The function `read_entry` does not conform to our usual coding style of
      returning stuff via the out parameter and to use the return value for
      reporting errors. Due to most of our code conforming to that pattern, it
      has become quite natural for us to actually return `-1` in case there is
      any error, which has also slipped in with commit 5625d86b (index:
      support index v4, 2016-05-17). As the function returns an `size_t` only,
      though, the return value is wrapped around, causing the caller of
      `read_tree` to continue with an invalid index entry. Ultimately, this
      can lead to a double-free.
      
      Improve code and fix the bug by converting the function to return the
      index entry size via an out parameter and only using the return value to
      indicate errors.
      
      Reported-by: Krishna Ram Prakash R <krp@gtux.in>
      Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
      Patrick Steinhardt committed
  9. 08 Mar, 2018 3 commits
  10. 07 Mar, 2018 3 commits
  11. 04 Mar, 2018 2 commits
  12. 03 Mar, 2018 1 commit
  13. 02 Mar, 2018 2 commits
  14. 28 Feb, 2018 1 commit