1. 18 Jan, 2020 10 commits
  2. 16 Jan, 2020 6 commits
    • Aaron Jones's avatar
      m4/atheme-print-configuration.m4: indicate if scrypt is available · b435404f
      Aaron Jones authored
      Also group password hashing modules together on their own.
      [ci skip]
    • Aaron Jones's avatar
      Compiler Sanitizers: Don't warn for unsigned integer overflow · 53cc3754
      Aaron Jones authored
      This is well-defined behaviour. Leaving it enabled produces tons
      of unnecessary noise.
    • Aaron Jones's avatar
      scripts/ci-build.sh: when building with sanitizers, don't do -Wl,-z,defs · 1ca7d0a1
      Aaron Jones authored
      This prevents linking, and the configure script checks for it for that
    • Aaron Jones's avatar
      configure: replace --enable-debugging with --enable-compiler-sanitizers · 3f9992da
      Aaron Jones authored
      This enables ASan, UBSan, et al. and supports both GCC and Clang.
      Clang support requires an LLVM-bitcode-parsing-capable linker (because
      Clang requires LTO for these sanitizers, and Clang in LTO mode outputs
      LLVM bitcode, instead of machine code, leaving it to the linker to
      translate it after performing its link-time optimisations).
      If you need to, pass LDFLAGS="-fuse-ld=lld" to override the LD variable
      set by `./configure` (which isn't used anyway) and use the LLVM linker.
      Alternatively, use the Gold linker with the LLVM plugin.
      Or just use GCC, but that doesn't support as many sanitizers ...
      This commit removes the `--enable-debugging` flag added by commit
      447cda49. It wasn't particularly useful anyway. The build
      system still checks for CFLAGS="-g", with or without this new option, &
      with or without any explicit CFLAGS being passed to `./configure`, so
      that the occasionally-submitted backtraces are at least still somewhat
      This commit also makes the CI build script pass the following options
      to `./configure`:
          --enable-compiler-sanitizers              (this newly-added option)
      The former is so that the sanitizers can catch any memory issues. The
      shared heap allocator(s) hide use-after-free problems, because they
      don't taint the memory, or release it back to the OS, after Atheme
      "frees" it.
    • Aaron Jones's avatar
    • Aaron Jones's avatar
      libathemecore/memory_fe_sodium: several small improvements · f848a96c
      Aaron Jones authored
      - Correct opening header comment block.
      - Document why a list of allocations is needed.
      - Use C99-style comments for single-line comments.
      - When performing a new memory allocation, and freeing an existing
        allocation, don't iterate the entire list of allocations and change
        the memory protection permissions on everything; only change what
        is necessary.
      - When performing a new memory allocation, add the new allocation to
        the head of the allocations list. Statistically speaking, the most
        recently-allocated memory is the memory that is most likely to be
        freed soon. This makes freeing it faster, because it's closer to
        the start of the list that you need to iterate over.
      - When freeing the information about an allocation, also free the
        allocation itself. This avoids needing to do so in the 3 places
        that free allocation information, which removes some duplication.
      - Remove an unnecessary typecast.
      - Liberally comment everything.
  3. 15 Jan, 2020 13 commits
  4. 14 Jan, 2020 1 commit
  5. 11 Jan, 2020 1 commit
  6. 10 Jan, 2020 9 commits