1. 18 Oct, 2019 3 commits
    • reflog: allow adding entries with newlines in their message · d8233feb
      Currently, the reflog disallows any entries that have a message with
      newlines, as that would effectively break the reflog format, which may
      contain a single line per entry, only. Upstream git behaves a bit
      differently, though, especially when considering stashes: instead of
      rejecting any reflog entry with newlines, git will simply replace
      newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
      create a reflog entry with "foo bar" as entry message.
      
      This commit adjusts our own logic to stop rejecting commit messages with
      newlines. Previously, this logic was part of `git_reflog_append`, only.
      There is a second place though where we add reflog entries, which is the
      serialization code in the filesystem refdb. As it didn't contain any
      sanity checks whatsoever, the refdb would have been perfectly happy to
      write malformatted reflog entries to the disk. This is being fixed with
      the same logic as for the reflog itself.
      Patrick Steinhardt committed
    • stash: modernize code style of `git_stash_save` · ca2d34a8
      The code style of `git_stash_save` doesn't really match our current
      coding style. Update it to match our current policies more closely.
      Patrick Steinhardt committed
  2. 11 Oct, 2019 2 commits
  3. 10 Oct, 2019 3 commits
    • refs: fix locks getting forcibly removed · 3335a034
      The flag GIT_FILEBUF_FORCE currently does two things:
           1. It will cause the filebuf to create non-existing leading
              directories for the file that is about to be written.
           2. It will forcibly remove any pre-existing locks.
      While most call sites actually do want (1), they do not want to
      remove pre-existing locks, as that renders the locking mechanisms
      effectively useless.
      Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
      separate both behaviours cleanly from each other and convert
      callers to use it instead of `GIT_FILEBUF_FORCE` to have them
      honor locked files correctly.
      
      As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
      this commit removes the flag altogether.
      Sebastian Henke committed
    • Merge pull request #5248 from dlax/parse-patch-empty-files · 6716e2f3
      patch_parse: handle patches with new empty files
      Patrick Steinhardt committed
    • cmake: update minimum CMake version to v3.5.1 · ebabb88f
      Back in commit cf9f3452 (cmake: bump minimum version to 2.8.11,
      2017-09-06), we have bumped the minimum CMake version to require at
      least v2.8.11. The main hold-backs back then were distributions like
      RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
      more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
      has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
      fair to upgrade to a more recent version.
      
      Going through repology [1], one can see that all supported mainstream
      distributions do in fact have CMake 3 available. Going through the list,
      the minimum version that is supported by all mainstream distros is in
      fact v3.5.1:
      
      	- CentOS 6 via EPEL6: 3.6.1
      	- Debian Oldstable: 3.7.2
      	- Fedora 26: 3.8.2
      	- OpenMandriva 3.x: 3.5.1
      	- Slackware 14.2: 3.5.2
      	- Ubuntu 16.04: 3.5.1
      
      Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
      remove all the version CMake checks that aren't required anymore.
      
      [1]: https://repology.org/project/cmake/versions
      Patrick Steinhardt committed
  4. 03 Oct, 2019 4 commits
  5. 28 Sep, 2019 3 commits
  6. 27 Sep, 2019 1 commit
  7. 26 Sep, 2019 2 commits
  8. 21 Sep, 2019 12 commits
    • azure: avoid building and testing in Docker as root · 3c884cc3
      Right now, all tests in libgit2's CI are being executed as root
      user. As libgit2 will usually not run as a root user in "normal"
      usecases and furthermore as there are tests that rely on the
      ability to _not_ be able to create certain paths, let's instead
      create an unprivileged user "libgit2" and use that across all
      docker images.
      Patrick Steinhardt committed
    • Merge pull request #5240 from pks-t/pks/valgrind-suppress-gcrypt · 9cd5240e
      valgrind: suppress memory leaks in libssh2_session_handshake
      Patrick Steinhardt committed
    • valgrind: suppress memory leaks in libssh2_session_handshake · 56d5b443
      On Ubuntu, the combination of libgcrypt and libssh2 is quite old and
      known to contain memory leaks. We thus have several functions listed in
      our suppressions file that are known to leak. Due to a recent update of
      libssh2 or libgcrypt, there now are new memory leaks caused by
      libssh2_session_handshake and libssh2_init that cause the CI to fail.
      
      Add a new suppression to fix the issue.
      Patrick Steinhardt committed
    • Merge pull request #5232 from pks-t/pks/buffer-ensure-size-oom · 3c1aa232
      buffer: fix writes into out-of-memory buffers
      Edward Thomson committed
    • posix: remove superseded POSIX regex wrappers · f585b129
      The old POSIX regex wrappers have been superseded by our own regexp API
      that provides a higher-level abstraction. Remove the POSIX wrappers in
      favor of the new one.
      Patrick Steinhardt committed
    • global: convert all users of POSIX regex to use our new regexp API · 7aacf027
      The old POSIX regex API has been superseded by our new regexp API.
      Convert all users to make use of the new one.
      Patrick Steinhardt committed
    • regexp: implement new regular expression API · d77378eb
      We currently support a set of different regular expression backends with
      PCRE, PCRE2, regcomp(3P) and regcomp_l(3). The current implementation of
      this is done via a simple POSIX wrapper that either directly uses
      supplied functions or that is a very small wrapper.
      
      To support PCRE and PCRE2, we use their provided <pcreposix.h> and
      <pcre2posix.h> wrappers. These wrappers are implemented in such a way
      that the accompanying libraries pcre-posix and pcre2-posix provide the
      same symbols as the libc ones, namely regcomp(3P) et al. This works out
      on some systems just fine, most importantly on glibc-based ones, where
      the regular expression functions are implemented as weak aliases and
      thus get overridden by linking in the pcre{,2}-posix library. On other
      systems we depend on the linking order of libc and pcre library, and as
      libc always comes first we will end up with the functions of the libc
      implementation. As a result, we may use the structures `regex_t` and
      `regmatch_t` declared by <pcre{,2}posix.h>, but use functions defined by
      the libc, leading to segfaults.
      
      The issue is not easily solvable. Somed distributions like Debian have
      resolved this by patching PCRE and PCRE2 to carry custom prefixes to all
      the POSIX function wrappers. But this is not supported by upstream and
      thus inherently unportable between distributions. We could instead try
      to modify linking order, but this starts becoming fragile and will not
      work e.g. when libgit2 is loaded via dlopen(3P) or similar ways. In the
      end, this means that we simply cannot use the POSIX wrappers provided by
      the PCRE libraries at all.
      
      Thus, this commit introduces a new regular expression API. The new API
      is on a tad higher level than the previous POSIX abstraction layer, as
      it tries to abstract away any non-portable flags like e.g. REG_EXTENDED,
      which has no equivalents in all of our supported backends. As there are
      no users of POSIX regular expressions that do _not_ reguest REG_EXTENDED
      this is fine to be abstracted away, though. Due to the API being
      higher-level than before, it should generally be a tad easier to use
      than the previous one.
      
      Note: ideally, the new API would've been called `git_regex_foobar` with
      a file "regex.h" and "regex.c". Unfortunately, this is currently
      impossible to implement due to naming clashes between the then-existing
      "regex.h" and <regex.h> provided by the libc. As we add the source
      directory of libgit2 to the header search path, an include of <regex.h>
      would always find our own "regex.h". Thus, we have to take the bitter
      pill of adding one more character to all the functions to disambiguate
      the includes.
      
      To improve guarantees around cross-backend compatibility, this commit
      also brings along an improved regular expression test suite
      core::regexp.
      Patrick Steinhardt committed
    • 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
    • Merge pull request #5237 from tiennou/fix/gssapi-cred · bfdb9793
      cred: add missing private header in GSSAPI block
      Patrick Steinhardt committed
    • cred: add missing private header in GSSAPI block · 49a3289e
      Should have been part of 8bf0f7eb
      Etienne Samson committed
  9. 19 Sep, 2019 3 commits
  10. 15 Sep, 2019 1 commit
  11. 14 Sep, 2019 2 commits
  12. 13 Sep, 2019 4 commits