Debian has a more stable retention period for pinned dependencies (the
version of OpenJDK 8 we were using for Ubuntu is gone already!), and
it matches what the Signal-Android repository is doing.
We're optimizing for size overhead in this encoding, so forego the
flexibility of protobufs in favor of a flat encoding (though one that
still uses protobuf's varints). Additionally, this encoding includes
the recipients inline in the message so the client can dump it all to
server in one go.
As a side effect, this means an SSv2 message encoded for sending no
longer has the same format as one encoded for receiving when there's
only one recipient. Consequently, all the tests need to be modified to
"fan out" a multi-recipient message to several single-recipient
messages. For simplicity, the wrapper language tests only support this
operation for SSv2 messages sent to exactly one recipient.
- Add a new "multi-recipient encrypt" entry point
- Add an "encrypt v1 sealed sender from UnidentifiedSenderMessage-
Content" entry point
- Add a public constructor for UnidentifiedSenderMessageContent
- Change group_encrypt to return a CiphertextMessage instead of bytes,
so it can be used with the above
- Java: add SenderKeyStore to SignalProtocolStore requirements
Unlike the other two bridges, the Java representation of a
CiphertextMessage uses an interface with implementing classes, rather
than an opaque wrapper. But bridge_fn's ResultTypeInfo can model this
too, and it simplifies things to do so.
It's a payload message, something that would go inside a SignalMessage
or PreKeySignalMessage. Drop it from all the enums, and while we're
here let's sync up the CiphertextMessageType::SenderKey case with the
sealed sender content type and the envelope content type.
With distribution IDs embedded in SenderKeyMessage and
SenderKeyDistributionMessage, the abstraction of SenderKeyName (a
sender address + distribution ID tuple) is no longer pulling its
weight. Remove it from the implementation and the public API.
The distribution ID is used to identify which key a particular sender
is using to encrypt their SenderKeyMessage, so it has to be known as
part of decryption. The previous design had the distribution ID stored
alongside each message (perhaps on the "envelope" structure that's
received from the server), but that's harder to keep track of, and it
would only be present for certain message kinds anyway.
Clarifies the use of "ID" in SenderKey-related APIs. I've left
deprecated entry points for Java but not for Swift and TypeScript
(which are not in use yet).
- SenderKeyMessage::key_id -> chain_id (avoids double "key" in name)
- SenderKeyDistributionMessage::id -> chain_id (to match SKM)
- SenderKeyName::group_id -> distribution_id (it's not the global group ID)
As Java has no concept of slices and we need some way of doing partial
updates, since this is required to implement the JCE Cipher interface,
and Android uses it.
Previously we defined one entry point for FFI (Swift) that took an
extra "context" parameter (to pass through iOS's database
transactions), and one for JNI+Node that did not (no context needed
currently). But this is all in our glue layer, which doesn't need to
be a perfect reflection of the outside interface. Remove that
duplication by accepting a Context parameter for both JNI and Node
that, for now, must be null.
By disallowing arbitrary expressions, bridge_get_bytearray (and
bridge_get_optional_bytearray) ends up a lot more like bridge_get,
and can reuse the infrastructure in bridge_fn_buffer instead of
needing a separate per-bridge implementation.
Additionally, never look up a session by e164 when decrypting
sealed-sender messages.
This is an API-breaking change for both Java and Swift clients;
certain fields and arguments are no longer Optional. On top of that,
some tests may need to be updated to provide UUIDs instead of just
phone numbers.
Replaces per-bridge implementations. Unfortunately, the other macros
are a little harder:
- bridge_deserialize and bridge_destroy allow customizing the /type/
name rather than the final function name
- bridge_get[_optional]_bytearray avoids extra copies differently from
bridge_fn_buffer
This reorders the FFI arguments to put the output at the front, a
convention we've been slowly moving towards anyway.
