1. 14 Dec, 2017 1 commit
  2. 08 Dec, 2017 1 commit
  3. 06 Dec, 2017 1 commit
  4. 01 Dec, 2017 2 commits
  5. 30 Nov, 2017 7 commits
    • Merge pull request #4426 from pks-t/pks/diff-flag-set-fix · 494a2f23
      diff_generate: fix unsetting diff flags
      Edward Thomson committed
    • Merge pull request #4424 from tiennou/fix/incorrect-winhttp-cert-payload · 6cf53e8f
      Use the same cert checking payload in WinHTTP
      Edward Thomson committed
    • openssl: fix thread-safety on non-glibc POSIX systems · 2d2e70f8
      While the OpenSSL library provides all means to work safely in a
      multi-threaded application, we fail to do so correctly. Quoting from
      crypto_lock(3):
      
          OpenSSL can safely be used in multi-threaded applications provided
          that at least two callback functions are set, locking_function and
          threadid_func.
      
      We do in fact provide the means to set up the locking function via
      `git_openssl_set_locking()`, where we initialize a set of locks by using
      the POSIX threads API and set the correct callback function to lock and
      unlock them.
      
      But what we do not do is setting the `threadid_func` callback. This
      function is being used to correctly locate thread-local data of the
      OpenSSL library and should thus return per-thread identifiers. Digging
      deeper into OpenSSL's documentation, the library does provide a fallback
      in case that locking function is not provided by the user. On Windows
      and BeOS we should be safe, as it simply "uses the system's default
      thread identifying API". On other platforms though OpenSSL will fall
      back to using the address of `errno`, assuming it is thread-local.
      
      While this assumption holds true for glibc-based systems, POSIX in fact
      does not specify whether it is thread-local or not. Quoting from
      errno(3p):
      
          It is unspecified whether errno is a macro or an identifier declared
          with external linkage.
      
      And in fact, with musl there is at least one libc implementation which
      simply declares `errno` as a simple `int` without being thread-local. On
      those systems, the fallback threadid function of OpenSSL will not be
      thread-safe.
      
      Fix this by setting up our own callback for this setting. As users of
      libgit2 may want to set it themselves, we obviously cannot always set
      that function on initialization. But as we already set up primitives for
      threading in `git_openssl_set_locking()`, this function becomes the
      obvious choice where to implement the additional setup.
      Patrick Steinhardt committed
    • diff_generate: fix unsetting diff flags · 5ca3f115
      The macro `DIFF_FLAG_SET` can be used to set or unset a flag by
      modifying the diff's bitmask. While the case of setting the flag is
      handled correctly, the case of unsetting the flag was not. Instead of
      inverting the flags, we are inverting the value which is used to decide
      whether we want to set or unset the bits.
      
      The value being used here is a simple `bool` which is `false`. As that
      is being uplifted to `int` when getting the bitwise-complement, we will
      end up retaining all bits inside of the bitmask. As that's only ever
      used to set `GIT_DIFF_IGNORE_CASE`, we were actually always ignoring
      case for generated diffs.
      
      Fix that by instead getting the bitwise-complement of `FLAG`, not `VAL`.
      Patrick Steinhardt committed
    • diff: remove unused macros `DIFF_FLAG_*` · 90fc7f53
      In commit 9be638ec (git_diff_generated: abstract generated diffs,
      2016-04-19), the code for generated diffs was moved out of the generic
      "diff.c" and instead into its own module. During that conversion, it was
      forgotten to remove the macros `DIFF_FLAG_IS_SET`, `DIFF_FLAG_ISNT_SET`
      and `DIFF_FLAG_SET`, which are now only used in "diff_generated.c".
      
      Remove those macros now.
      Patrick Steinhardt committed
    • Merge pull request #4422 from pks-t/pks/commit-msg-style · a9b66677
      CONTRIBUTING: add documentation of our commit message style
      Edward Thomson committed
  6. 26 Nov, 2017 1 commit
  7. 25 Nov, 2017 2 commits
  8. 24 Nov, 2017 10 commits
  9. 22 Nov, 2017 1 commit
  10. 19 Nov, 2017 2 commits
  11. 18 Nov, 2017 2 commits
    • Merge pull request #4420 from pks-t/pks/strict-aliasing · a8f19f81
      refcount: make refcounting conform to aliasing rules
      Carlos Martín Nieto committed
    • refcount: make refcounting conform to aliasing rules · 585b5dac
      Strict aliasing rules dictate that for most data types, you are not
      allowed to cast them to another data type and then access the casted
      pointers. While this works just fine for most compilers, technically we
      end up in undefined behaviour when we hurt that rule.
      
      Our current refcounting code makes heavy use of casting and thus
      violates that rule. While we didn't have any problems with that code,
      Travis started spitting out a lot of warnings due to a change in their
      toolchain. In the refcounting case, the code is also easy to fix:
      as all refcounting-statements are actually macros, we can just access
      the `rc` field directly instead of casting.
      
      There are two outliers in our code where that doesn't work. Both the
      `git_diff` and `git_patch` structures have specializations for generated
      and parsed diffs/patches, which directly inherit from them. Because of
      that, the refcounting code is only part of the base structure and not of
      the children themselves. We can help that by instead passing their base
      into `GIT_REFCOUNT_INC`, though.
      Patrick Steinhardt committed
  12. 15 Nov, 2017 1 commit
  13. 14 Nov, 2017 4 commits
  14. 13 Nov, 2017 2 commits
  15. 12 Nov, 2017 3 commits