Like other crypto libs, libolm contains many obstacles which a fuzzer is
unlikely to be able to surmount but which are not important for the end
goal of fuzzing. The easiest and most robust way around this is to remove
these obstacles conditionally when building the fuzzer binaries.

This commit adds a preprocessor macro OLM_FUZZING which can be used to
conditionally disables problematic bits of code during compile-time for
easier fuzzing.

Currently the only thing it disables is the encryption/decryption and
base64 encoding/decoding when processing pickled Megolm keys. This
allows the fuzzers to fuzz the unpickling functionality directly without
inadvertently fuzzing the base64 encoder and encryption (which should be
fuzzed separately).

The macro is set in the Makefile *only* when building fuzzer binaries.

Prints the list of exported functions from a built library object.
Useful for sanity checking.

- `compile_commands.json`: clang compilation database
- `.ccls-cache`: Cache directory for the ccls language server
- `.clang-format`: clang formatting description

Denis Kasak authored Jun 30, 2021 and Hubert Chathi committed Jul 08, 2021

See https://editorconfig.org/ for more information.

Johannes Hayeß authored Jun 27, 2021 and Hubert Chathi committed Jun 29, 2021

Hi,

currently tests don't build with MSVC, because the Base64 test tries to initialize multiple arrays with a length value that was derived from a non-const context. I have fixed this by using vectors instead.

Sincerely

Johannes Hayeß

From 2d76972a862f0aa04b5011537bef71a49aa82a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Johannes=20Haye=C3=9F?= <jhaye@mailbox.org>
Date: Sun, 27 Jun 2021 17:46:24 +0200
Subject: [PATCH] Fix compiling with MSVC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Previously attempts to initialize arrays with non-const value. This
seemingly works on GCC/clang due to their static code analysis, but
fails with MSVC. This switches to dynamic memory allocation with
std::vector, to solve the problem.

Signed-off-by: Johannes Hayeß <jhaye@mailbox.org>

Denis Kasak authored May 20, 2021 and Hubert Chathi committed Jun 04, 2021

The old docstring was the same as olm_create_inbound_session and didn't
explain the difference between them.

This type of instrumentation is much faster (several times over) and
supports much more features than afl-gcc/afl-g++, though it requires
a LLVM/clang installation.

olm::decode_base64 now returns the length of the raw decoded data on
success. When given input with an invalid base64 length, it fails early
(before decoding any input) and returns -1.

This also makes the C function _olm_decode_base64 an actual binding of
olm::decode_base64 instead of a wrapper with slightly different
behaviour.

As a precaution.

_olm_decode_group_message should initialize all fields of the results
struct before returning. This is because its caller
_decrypt_max_plaintext_length relies on it having initialized these
fields.

Luckily, this only allows one to subvert the version check in
_decrypt_max_plaintext_length, but not the following check that the
ciphertext field is non-null because that field *is* initialized.