1. 09 Nov, 2021 1 commit
  2. 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
  3. 30 Aug, 2021 1 commit
  4. 27 Aug, 2021 2 commits
  5. 27 Jul, 2021 1 commit
  6. 07 Jan, 2021 1 commit
  7. 15 Dec, 2020 1 commit
  8. 06 Dec, 2020 1 commit
  9. 29 Nov, 2020 1 commit
    • Make the pack and mwindow implementations data-race-free · 322c15ee
      This change fixes a packfile heap corruption that can happen when
      interacting with multiple packfiles concurrently across multiple
      threads. This is exacerbated by setting a lower mwindow open file limit.
      
      This change:
      
      * Renames most of the internal methods in pack.c to clearly indicate
        that they expect to be called with a certain lock held, making
        reasoning about the state of locks a bit easier.
      * Splits the `git_pack_file` lock in two: the one in `git_pack_file`
        only protects the `index_map`. The protection to `git_mwindow_file` is
        now in that struct.
      * Explicitly checks for freshness of the `git_pack_file` in
        `git_packfile_unpack_header`: this allows the mwindow implementation
        to close files whenever there is enough cache pressure, and
        `git_packfile_unpack_header` will reopen the packfile if needed.
      * After a call to `p_munmap()`, the `data` and `len` fields are poisoned
        with `NULL` to make use-after-frees more evident and crash rather than
        being open to the possibility of heap corruption.
      * Adds a test case to prevent this from regressing in the future.
      
      Fixes: #5591
      lhchavez committed
  10. 28 Nov, 2020 1 commit
  11. 27 Nov, 2020 2 commits
  12. 05 Oct, 2020 1 commit
  13. 05 Aug, 2020 2 commits
    • zstream: handle Z_BUF_ERROR appropriately in get_output_chunk · 9bb61bad
      Our processing loop in git_zstream_get_output_chunk does not handle
      `Z_BUF_ERROR` appropriately at the end of a compressed window.
      
      From the zlib manual, inflate will return:
      
      > Z_BUF_ERROR if no progress was possible or if there was not enough
      > room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR
      > is not fatal, and inflate() can be called again with more input and
      > more output space to continue decompressing.
      
      In our loop, we were waiting until we got the expected size, then
      ensuring that we were at `Z_STREAM_END`.  We are not guaranteed to be,
      since zlib may be in the `Z_BUF_ERROR` state where it has consumed a
      full window's worth of data, but it doesn't know that it's really at the
      end of the stream.  There _could_ be more compressed data, but it
      doesn't _know_ that there's not until we make a subsequent call.
      
      We can change the loop to look for the end of stream instead of our
      expected size.  This allows us to call inflate one last time when we are
      at the end of a window (and in the `Z_BUF_ERROR` state), allowing it to
      recognize the end of the stream, and move from the `Z_BUF_ERROR` state
      to the `Z_STREAM_END` state.
      
      If we do this, we need another exit condition: when `bytes == 0`, then
      no progress could be made and we should stop trying to inflate.  This
      will be an error case, caught by the size and/or end-of-stream test.
      Edward Thomson committed
  14. 02 Apr, 2020 1 commit
  15. 01 Apr, 2020 2 commits
  16. 07 Feb, 2020 1 commit
  17. 09 Jan, 2020 2 commits
  18. 25 Nov, 2019 1 commit
  19. 20 Jul, 2019 1 commit
  20. 15 Feb, 2019 4 commits
    • offmap: introduce high-level setter for key/value pairs · b9d0b664
      Currently, there is only one caller that adds entries into an offset map, and
      this caller first uses `git_offmap_put` to add a key and then set the value at
      the returned index by using `git_offmap_set_value_at`. This is just too tighlty
      coupled with implementation details of the map as it exposes the index of
      inserted entries, which we really do not care about at all.
      
      Introduce a new function `git_offmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert the caller to make use
      of it instead.
      Patrick Steinhardt committed
    • offmap: introduce high-level getter for values · aa245623
      The current way of looking up an entry from a map is tightly coupled with the
      map implementation, as one first has to look up the index of the key and then
      retrieve the associated value by using the index. As a caller, you usually do
      not care about any indices at all, though, so this is more complicated than
      really necessary. Furthermore, it invites for errors to happen if the correct
      error checking sequence is not being followed.
      
      Introduce a new high-level function `git_offmap_get` that takes a map and a key
      and returns a pointer to the associated value if such a key exists. Otherwise,
      a `NULL` pointer is returned. Adjust all callers that can trivially be
      converted.
      Patrick Steinhardt committed
    • oidmap: introduce high-level getter for values · 9694ef20
      The current way of looking up an entry from a map is tightly coupled with the
      map implementation, as one first has to look up the index of the key and then
      retrieve the associated value by using the index. As a caller, you usually do
      not care about any indices at all, though, so this is more complicated than
      really necessary. Furthermore, it invites for errors to happen if the correct
      error checking sequence is not being followed.
      
      Introduce a new high-level function `git_oidmap_get` that takes a map and a key
      and returns a pointer to the associated value if such a key exists. Otherwise,
      a `NULL` pointer is returned. Adjust all callers that can trivially be
      converted.
      Patrick Steinhardt committed
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  21. 02 Feb, 2019 1 commit
  22. 22 Jan, 2019 1 commit
  23. 17 Jan, 2019 1 commit
  24. 01 Dec, 2018 1 commit
  25. 28 Nov, 2018 1 commit
  26. 10 Jun, 2018 2 commits
  27. 23 Dec, 2017 1 commit
    • Fix unpack double free · c3514b0b
      If an element has been cached, but then the call to
      packfile_unpack_compressed() fails, the very next thing that happens is
      that its data is freed and then the element is not removed from the
      cache, which frees the data again.
      
      This change sets obj->data to NULL to avoid the double-free. It also
      stops trying to resolve deltas after two continuous failed rounds of
      resolution, and adds a test for this.
      lhchavez committed
  28. 15 Dec, 2017 1 commit
  29. 09 Dec, 2017 1 commit
  30. 08 Dec, 2017 1 commit
    • libFuzzer: Prevent a potential shift overflow · 28662c13
      The type of |base_offset| in get_delta_base() is `git_off_t`, which is a
      signed `long`. That means that we need to make sure that the 8 most
      significant bits are zero (instead of 7) to avoid an overflow when it is
      shifted by 7 bits.
      
      Found using libFuzzer.
      lhchavez committed
  31. 09 Aug, 2017 1 commit
    • sha1_lookup: drop sha1_entry_pos function · 9842b327
      This was pulled over from git.git, and is an experiment in
      making binary-searching lists of sha1s faster. It was never
      compiled by default (nor was it used upstream by default
      without a special environment variable).
      
      Unfortunately, it is actually slower in practice, and
      upstream is planning to drop it in
      git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has
      some timing results). It's worth doing the same here for
      simplicity.
      Jeff King committed