1. 14 Jul, 2022 1 commit
  2. 20 Jun, 2022 1 commit
  3. 15 Jun, 2022 1 commit
  4. 23 Feb, 2022 1 commit
  5. 11 Nov, 2021 1 commit
  6. 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
  7. 29 Jun, 2018 1 commit
    • delta: fix sign-extension of big left-shift · 7db25870
      Our delta code was originally adapted from JGit, which itself adapted it
      from git itself. Due to this heritage, we inherited a bug from git.git
      in how we compute the delta offset, which was fixed upstream in
      48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As
      explained by Linus:
      
          Shifting 'unsigned char' or 'unsigned short' left can result in sign
          extension errors, since the C integer promotion rules means that the
          unsigned char/short will get implicitly promoted to a signed 'int' due to
          the shift (or due to other operations).
      
          This normally doesn't matter, but if you shift things up sufficiently, it
          will now set the sign bit in 'int', and a subsequent cast to a bigger type
          (eg 'long' or 'unsigned long') will now sign-extend the value despite the
          original expression being unsigned.
      
          One example of this would be something like
      
                  unsigned long size;
                  unsigned char c;
      
                  size += c << 24;
      
          where despite all the variables being unsigned, 'c << 24' ends up being a
          signed entity, and will get sign-extended when then doing the addition in
          an 'unsigned long' type.
      
          Since git uses 'unsigned char' pointers extensively, we actually have this
          bug in a couple of places.
      
      In our delta code, we inherited such a bogus shift when computing the
      offset at which the delta base is to be found. Due to the sign extension
      we can end up with an offset where all the bits are set. This can allow
      an arbitrary memory read, as the addition in `base_len < off + len` can
      now overflow if `off` has all its bits set.
      
      Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned
      integer again. Add a test with a crafted delta that would actually
      succeed with an out-of-bounds read in case where the cast wouldn't
      exist.
      
      Reported-by: Riccardo Schirone <rschiron@redhat.com>
      Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
      Patrick Steinhardt committed
  8. 10 Jun, 2018 1 commit
  9. 25 Sep, 2015 1 commit
    • Fix binary diffs · e4b2b919
      git expects an empty line after the binary data:
      
      literal X
      ...binary data...
      <empty_line>
      
      The last literal block of the generated patches were not containing the required empty line. Example:
      
      	diff --git a/binary_file b/binary_file
      	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 6
      	Nc${NM%g@i}0ssZ|0lokL
      	diff --git a/binary_file2 b/binary_file2
      	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 13
      	Sc${NMEKbZyOexL+Qd|HZV+4u-
      
      git apply of that diff results in:
      
      	error: corrupt binary patch at line 9: diff --git a/binary_file2 b/binary_file2
      	fatal: patch with only garbage at line 10
      
      The proper formating is:
      
      	diff --git a/binary_file b/binary_file
      	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 6
      	Nc${NM%g@i}0ssZ|0lokL
      	diff --git a/binary_file2 b/binary_file2
      	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
      	GIT binary patch
      	literal 8
      	Pc${NM&PdElPvrst3ey5{
      
      	literal 13
      	Sc${NMEKbZyOexL+Qd|HZV+4u-
      Guille -bisho- committed
  10. 26 Jun, 2015 2 commits
  11. 24 Jun, 2015 2 commits
  12. 15 Jun, 2015 1 commit
  13. 12 Jun, 2015 2 commits
  14. 23 Apr, 2014 1 commit