1. 09 Feb, 2022 1 commit
    • rand: introduce git_rand PRNG · 3c53796c
      Introduce `git_rand`, a PRNG based on xoroshiro256**, a fast,
      all-purpose pseudo-random number generator: https://prng.di.unimi.it
      
      The PRNG will be seeded by the system's entropy store when possible,
      falling back to current time and system data (pid, uptime, etc).
      Inspiration for this was taken from libressl, but since our PRNG is
      not used for cryptographic purposes (and indeed currently only generates
      a unique temp file name that is written in a protected directory),
      this should be more than sufficient.
      
      Our implementation of xoroshiro256** was taken almost strictly from
      the original author's sources, but was tested against PractRand to
      ensure that there were no foolish mistranslations:
      
      ```
      RNG_test using PractRand version 0.94
      RNG = RNG_stdin64, seed = unknown
      test set = core, folding = standard (64 bit)
      
      rng=RNG_stdin64, seed=unknown
      length= 256 megabytes (2^28 bytes), time= 2.9 seconds
        no anomalies in 210 test result(s)
      
      rng=RNG_stdin64, seed=unknown
      length= 512 megabytes (2^29 bytes), time= 6.2 seconds
        no anomalies in 226 test result(s)
      
      rng=RNG_stdin64, seed=unknown
      length= 1 gigabyte (2^30 bytes), time= 12.7 seconds
        no anomalies in 243 test result(s)
      
      rng=RNG_stdin64, seed=unknown
      length= 2 gigabytes (2^31 bytes), time= 25.4 seconds
        no anomalies in 261 test result(s)
      
      rng=RNG_stdin64, seed=unknown
      length= 4 gigabytes (2^32 bytes), time= 50.6 seconds
        no anomalies in 277 test result(s)
      
      rng=RNG_stdin64, seed=unknown
      length= 8 gigabytes (2^33 bytes), time= 104 seconds
        no anomalies in 294 test result(s)
      ```
      Edward Thomson committed
  2. 11 Nov, 2021 1 commit
  3. 18 Oct, 2021 1 commit
  4. 24 Aug, 2021 1 commit
    • openssl: dynamically load libssl and symbols (optionally) · 0903cac1
      Provide an interface around OpenSSL to dynamically load the libraries
      and symbols, so that users can distribute a libgit2 library that is not
      linked directly against OpenSSL.  This enables users to target multiple
      distributions with a single binary.
      
      This mechanism is optional and disabled by default.  Configure cmake
      with -DUSE_HTTPS=OpenSSL-Dynamic to use it.
      Edward Thomson committed
  5. 08 Aug, 2021 1 commit
  6. 19 Jul, 2021 1 commit
    • alloc: add GIT_DEBUG_STRICT_ALLOC · 48e6b02b
      Add `GIT_DEBUG_STRICT_ALLOC` to help identify problematic callers of
      allocation code that pass a `0` size to the allocators and then expect a
      non-`NULL` return.
      
      When given a 0-size allocation, `malloc` _may_ return either a `NULL`
      _or_ a pointer that is not writeable.  Most systems return a non-`NULL`
      pointer; AIX is an outlier.  We should be able to cope with this AIXy
      behavior, so this adds an option to emulate it.
      Edward Thomson committed
  7. 21 Nov, 2020 1 commit
  8. 13 Oct, 2019 2 commits
  9. 10 Jun, 2019 2 commits
  10. 19 May, 2019 3 commits
  11. 28 Nov, 2018 1 commit
  12. 11 Apr, 2018 2 commits
  13. 16 Aug, 2017 2 commits
    • cmake: move regcomp and futimens checks to "features.h" · 8341d6cf
      In our CMakeLists.txt, we have to check multiple functions in order to
      determine if we have to use our own or whether we can use the
      platform-provided one. For two of these functions, namely `regcomp_l()`
      and `futimens`, the defined macro is actually used inside of the header
      file "src/unix/posix.h". As such, these macros are not only required by
      the library, but also by our test suite, which is makes use of internal
      headers.
      
      To prepare for the CMakeLists.txt split, move these two defines inside
      of the "features.h" header.
      Patrick Steinhardt committed
    • cmake: move defines into "features.h" header · a390a846
      In a future commit, we will split out the build instructions for our
      library directory and move them into a subdirectory. One of the benefits
      is fixing scoping issues, where e.g. defines do not leak to build
      targets where they do not belong to. But unfortunately, this does also
      pose the problem of how to propagate some defines which are required by
      both the library and the test suite.
      
      One way would be to create another variable keeping track of all added
      defines and declare it inside of the parent scope. While this is the
      most obvious and simplest way of going ahead, it is kind of unfortunate.
      The main reason to not use this is that these defines become implicit
      dependencies between the build targets. By simply observing a define
      inside of the CMakeLists.txt file, one cannot reason whether this define
      is only required by the current target or whether it is required by
      different targets, as well.
      
      Another approach would be to use an internal header file keeping track
      of all defines shared between targets. While configuring the library, we
      will set various variables and let CMake configure the file, adding or
      removing defines based on what has been configured. Like this, one can
      easily keep track of the current environment by simply inspecting the
      header file. Furthermore, these dependencies are becoming clear inside
      the CMakeLists.txt, as instead of simply adding a define, we now call
      e.g. `SET(GIT_THREADSAFE 1)`.
      
      Having this header file though requires us to make sure it is always
      included before any "#ifdef"-preprocessor checks are executed. As we
      have already refactored code to always include the "common.h" header
      file before any statement inside of a file, this becomes easy: just make
      sure "common.h" includes the new "features.h" header file first.
      Patrick Steinhardt committed