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.

Consider the case when the input is size 0. In this case, `count` and
`buffer_pos` will be 0 as well. The `realloc` call in the `count == 0`
branch will then effectively become a free.

However, `realloc` can sometimes return `NULL` when a 0 is passed for
the size. The current code assumes that this only happens on a memory
allocation error and breaks out of the loop. This then becomes a double
free because the buffer is freed a second time, causing an abort.

The intent of the `realloc` is probably to downsize the buffer to fit
the data exactly in order to make incorrect memory access more obvious.
This commit skips this downsizing if the size of the input data is 0.

EXTRA_EXPORTED_RUNTIME_METHODS is deprecated. Replace with
EXPORTED_RUNTIME_METHODS.

Fix URL to the NCC Group audit.

See merge request matrix-org/olm!22

The original URL is now redirecting to a generic listing page and there
are no links to the actual Olm audit paper there.

Signed-off-by: Lukas Lihotzki <lukas@lihotzki.de>

Update gradle wrapper and build tools

See merge request matrix-org/olm!20

Using command `./gradlew connectedAndroidTest` on an API 21 emulator

BuildConfig.VERSION_NAME is not available anymore when building library
Also replace JCenter by MavenCentral

Xcode: Add support of Swift Package Manager

See merge request matrix-org/olm!19

Made by Johennes at https://github.com/matrix-org/olm/issues/51#issuecomment-809128833

to be published via our gitlab repository

sas: Fix the base64 encoding of the MAC.

See merge request matrix-org/olm!16

OLMKit:  New pickle version using a pickle key provided externally

See merge request matrix-org/olm!17

Improve ObjC wrappers so that they can use a pickle key provided by the olm lib user.

This new behavior is optional to not break existing usage.

It is retro compatible and use pickle versioning already in place. 
Existing key will be unpickled with pickle v1 and pickled with pickle v2 if an external pickle key is provided. 

Since it's important to keep backwards compatibility introduce a new
function to calculate the MAC using a SAS object.

Modifying the existing functions would break compatibility with older
releases of libolm.

When calculating the MAC for a message using olm_sas_calculate_mac() and
olm_sas_calculate_mac_long_kdf() the resulting MAC will be base64
encoded using _olm_encode_base64().

The _olm_encode_base64() method requires an input buffer and output
buffer to be passed alongside the input length. The method is called
with the same buffer, containing the MAC, for the input buffer as well
as for the output buffer. This results in an incorrectly base64 encoded
MAC.

For example the byte array:
    [121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, 5,
     15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, 82, 158,
     168, 179, 10, 230]

will be encoded as  eWm7NyVeVmXgbVhnYlZobllsWm9ibGxzV205aWJHeHo
instead of as       eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY

Notice the different value at the 10th character.

The correct result can be independently checked using Python for
example:

>>> from base64 import b64encode
>>> mac = [121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, \
           5, 15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, \
           82, 158, 168, 179, 10, 230]
>>> b64encode(bytearray(mac)).rstrip(b"=")
>>> b'eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY'

This happens because the encode_base64() method that is used does not support
in-place encoding in the general case. This is because the remainder for a 32
bit input will always be 2 (32 % 6 == 2).

The remainder will be used over here:
https://gitlab.matrix.org/matrix-org/olm/-/blob/c01164f001d57fbe2297fe11954b58077a68dc0d/src/base64.cpp#L74

The logic that gets executed if a remainder exists depends on the original input
values, since those already got in-place encoded the whole block will behave
differently if the input buffer is the same as the output buffer.