1. 11 May, 2021 2 commits
  2. 25 Nov, 2020 3 commits
  3. 30 Jun, 2020 1 commit
    • Make the tests run cleanly under UndefinedBehaviorSanitizer · d0656ac8
      This change makes the tests run cleanly under
      `-fsanitize=undefined,nullability` and comprises of:
      
      * Avoids some arithmetic with NULL pointers (which UBSan does not like).
      * Avoids an overflow in a shift, due to an uint8_t being implicitly
        converted to a signed 32-bit signed integer after being shifted by a
        32-bit signed integer.
      * Avoids a unaligned read in libgit2.
      * Ignores unaligned reads in the SHA1 library, since it only happens on
        Intel processors, where it is _still_ undefined behavior, but the
        semantics are moderately well-understood.
      
      Of notable omission is `-fsanitize=integer`, since there are lots of
      warnings in zlib and the SHA1 library which probably don't make sense to
      fix and I could not figure out how to silence easily. libgit2 itself
      also has ~100s of warnings which are mostly innocuous (e.g. use of enum
      constants that only fit on an `uint32_t`, but there is no way to do that
      in a simple fashion because the data type chosen for enumerated types is
      implementation-defined), and investigating whether there are worrying
      warnings would need reducing the noise significantly.
      lhchavez committed
  4. 09 Jun, 2020 1 commit
    • tree-wide: do not compile deprecated functions with hard deprecation · c6184f0c
      When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor
      definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h"
      header to be empty. As a result, no function declarations are made
      available to callers, but the implementations are still available to
      link against. This has the problem that function declarations also
      aren't visible to the implementations, meaning that the symbol's
      visibility will not be set up correctly. As a result, the resulting
      library may not expose those deprecated symbols at all on some platforms
      and thus cause linking errors.
      
      Fix the issue by conditionally compiling deprecated functions, only.
      While it becomes impossible to link against such a library in case one
      uses deprecated functions, distributors of libgit2 aren't expected to
      pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually
      define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real"
      hard deprecation still makes sense in the context of CI to test we don't
      use deprecated symbols ourselves and in case a dependant uses libgit2 in
      a vendored way and knows it won't ever use any of the deprecated symbols
      anyway.
      Patrick Steinhardt committed
  5. 24 Jan, 2020 1 commit
  6. 21 Sep, 2019 3 commits
    • buffer: fix printing into out-of-memory buffer · 174b7a32
      Before printing into a `git_buf` structure, we always call `ENSURE_SIZE`
      first. This macro will reallocate the buffer as-needed depending on
      whether the current amount of allocated bytes is sufficient or not. If
      `asize` is big enough, then it will just do nothing, otherwise it will
      call out to `git_buf_try_grow`. But in fact, it is insufficient to only
      check `asize`.
      
      When we fail to allocate any more bytes e.g. via `git_buf_try_grow`,
      then we set the buffer's pointer to `git_buf__oom`. Note that we touch
      neither `asize` nor `size`. So if we just check `asize > targetsize`,
      then we will happily let the caller of `ENSURE_SIZE` proceed with an
      out-of-memory buffer. As a result, we will print all bytes into the
      out-of-memory buffer instead, resulting in an out-of-bounds write.
      
      Fix the issue by having `ENSURE_SIZE` verify that the buffer is not
      marked as OOM. Add a test to verify that we're not writing into the OOM
      buffer.
      Patrick Steinhardt committed
    • buffer: fix infinite loop when growing buffers · 208f1d7a
      When growing buffers, we repeatedly multiply the currently allocated
      number of bytes by 1.5 until it exceeds the requested number of bytes.
      This has two major problems:
      
          1. If the current number of bytes is tiny and one wishes to resize
             to a comparatively huge number of bytes, then we may need to loop
             thousands of times.
      
          2. If resizing to a value close to `SIZE_MAX` (which would fail
             anyway), then we probably hit an infinite loop as multiplying the
             current amount of bytes will repeatedly result in integer
             overflows.
      
      When reallocating buffers, one typically chooses values close to 1.5 to
      enable re-use of resulting memory holes in later reallocations. But
      because of this, it really only makes sense to use a factor of 1.5
      _once_, but not looping until we finally are able to fit it. Thus, we
      can completely avoid the loop and just opt for the much simpler
      algorithm of multiplying with 1.5 once and, if the result doesn't fit,
      just use the target size. This avoids both problems of looping
      extensively and hitting overflows.
      
      This commit also adds a test that would've previously resulted in an
      infinite loop.
      Patrick Steinhardt committed
    • buffer: fix memory leak if unable to grow buffer · 3e8a17b0
      If growing a buffer fails, we set its pointer to the static
      `git_buf__oom` structure. While we correctly free the old pointer if
      `git__malloc` returned an error, we do not free it if there was an
      integer overflow while calculating the new allocation size. Fix this
      issue by freeing the pointer to plug the memory leak.
      Patrick Steinhardt committed
  7. 25 Jan, 2019 1 commit
  8. 22 Jan, 2019 1 commit
  9. 10 Jun, 2018 2 commits
  10. 19 Mar, 2018 1 commit
  11. 08 Jun, 2017 3 commits
    • buffer: return errors for `git_buf_init` and `git_buf_attach` · 4796c916
      Both the `git_buf_init` and `git_buf_attach` functions may call
      `git_buf_grow` in case they were given an allocation length as
      parameter. As such, it is possible for these functions to fail when we
      run out of memory. While it won't probably be used anytime soon, it does
      indeed make sense to also record this fact by returning an error code
      from both functions. As they belong to the internal API only, this
      change does not break our interface.
      Patrick Steinhardt committed
    • buffer: consistently use `ENSURE_SIZE` to grow buffers on-demand · 9a8386a2
      The `ENSURE_SIZE` macro can be used to grow a buffer if its currently
      allocated size does not suffice a required target size. While most of
      the code already uses this macro, the `git_buf_join` and `git_buf_join3`
      functions do not yet use it. Due to the macro first checking whether we
      have to grow the buffer at all, this has the benefit of saving a
      function call when it is not needed. While this is nice to have, it will
      probably not matter at all performance-wise -- instead, this only serves
      for consistency across the code.
      Patrick Steinhardt committed
    • buffer: fix `ENSURE_SIZE` macro referencing wrong variable · e82dd813
      While the `ENSURE_SIZE` macro gets a reference to both the buffer that
      is to be resized and a new size, we were not consistently referencing
      the passed buffer, but instead a variable `buf`, which is not passed in.
      Funnily enough, we never noticed because our buffers seem to always be
      named `buf` whenever the macro was being used.
      
      Fix the macro by always using the passed-in buffer. While at it, add
      braces around all mentions of passed-in variables as should be done with
      macros to avoid subtle errors.
      
      Found-by: Edward Thompson
      Patrick Steinhardt committed
  12. 29 Dec, 2016 1 commit
  13. 26 May, 2016 4 commits
  14. 24 Jun, 2015 2 commits
  15. 19 Feb, 2015 1 commit
  16. 13 Feb, 2015 4 commits
  17. 09 Jan, 2015 1 commit
  18. 21 Nov, 2014 1 commit
  19. 15 Aug, 2014 1 commit
  20. 16 Jul, 2014 1 commit
  21. 08 May, 2014 1 commit
    • Be more careful with user-supplied buffers · 1e4976cb
      This adds in missing calls to `git_buf_sanitize` and fixes a
      number of places where `git_buf` APIs could inadvertently write
      NUL terminator bytes into invalid buffers.  This also changes the
      behavior of `git_buf_sanitize` to NUL terminate a buffer if it can
      and of `git_buf_shorten` to do nothing if it can.
      
      Adds tests of filtering code with zeroed (i.e. unsanitized) buffer
      which was previously triggering a segfault.
      Russell Belfer committed
  22. 23 Apr, 2014 1 commit
  23. 10 Apr, 2014 1 commit
  24. 01 Apr, 2014 1 commit
  25. 25 Feb, 2014 1 commit