These APIs are designed to match the generated "simpleapi" entry
points in the original zkgroup repository, to make it easier to adapt
the existing Java, Swift, and TypeScript code to libsignal-client.
The cbindgen-generated signal_ffi.h now includes constants, so that
the fixed-size arrays used to serialize zkgroup types can use named
constants in Rust. This meant filtering out some constants that were
getting picked up but that should not be included.
Note that this commit makes references to Java exception types that
will be added in a later commit.
This will be used by zkgroup. Note that in order to print the type
correctly in C, a type `Serialized<FooBar>` will be translated to
`[u8; FOO_BAR_LEN]`, where 'FOO_BAR_LEN' has to be a constant that's
in scope.
u64 can't be represented as a primitive in Java or TypeScript (and for
the latter, Neon doesn't support bigint yet). However, for timestamps
represented as milliseconds, the integer-safe range of float64 still
covers more than 285,000 years, so it's reasonably safe to use
TypeScript's 'number' or Java's 'long' to represent these
ostensibly-64-bit values. Indicate this with a new Timestamp wrapper
type in the bridge layer.
In theory we could push this new Timestamp type down to the
libsignal-protocol crate. However, the protocol itself doesn't impose
any restrictions on the timestamp fields, so I figured it was best to
put it at the bridge layer, to indicate that it's about how Signal
specifically uses these fields.
This commit paves the way for being stricter about *other* u64 values
that might want to use the full 64-bit space.
Unlike bridge_get or bridge_get_bytearray, bridge_deserialize doesn't
do any complicated transformation of the return value to accept
optional or non-optional, failable and non-failable results alike. At
the same time, its syntax has been subtly different from the other
bridge_fn macros, dating from when we were first setting up this
library. Since the extra parameters to rename or disable a particular
bridge's entry point were rarely used, this commit removes them and
replaces those use sites with spelled-out bridge_fns. This in turn
allows removing the custom per-bridge implementations of
bridge_deserialize in favor of a bridge_fn-based implementation like
bridge_get already has.
Previously, we had HKDF-for-session-version-3, which matches RFC 5869,
and HKDF-for-session-version-2, which produced slightly different
results. However, nothing in the current versions of Signal uses
anything but the RFC-compliant version. Therefore, this commit removes
support for version 2 and deprecates the entry points that take a
version:
- Java: The HKDFv3 class is deprecated in favor of static methods on
the HKDF class.
- Swift: The hkdf function that takes a 'version' parameter is
deprecated in favor of a new overload that does not.
- TypeScript: The HKDF class is deprecated in favor of a top-level
hkdf function.
- Rust: The libsignal-protocol implementation of HKDF has been removed
entirely in favor of the hkdf crate.
There are no significant benchmark deltas from this change, and a
minimal code size increase that's the cost for removing our own
implementation of HKDF. The deprecations can be removed as a later
breaking change.
On Windows, node-gyp tries to be helpful by changing forward slashes
to backslashes and making paths relative to the source root rather
than the build directory, and indeed we rely on that. However, it has
to guess what's a path and what isn't. Previously, we worked around
that by manually stripping the prepended "..\", but the node-gyp
maintainers suggested a better workaround of using joined arguments
instead (`--foo=bar` instead of `--foo bar`).
This dedicated error is thrown when a recipient has a registration ID
that's out of the range used by Signal [0, 0x3FFF]. These IDs cannot
be encoded in the sealed sender v2 format and are not supported, even
though they don't cause any problems for 1:1 messages.
This allows a device to know whether it's the one that sent a bad
message, and take action accordingly.
We could have a slightly more typesafe API here by using
ProtocolAddress and extracting the device ID, but that doesn't match
up with getting the device ID out of a sealed sender certificate.
- Default: sender will not resend; an error should be shown
immediately
- Resendable: sender will try to resend; delay any error UI if
possible
- Implicit: don't show any error UI at all; this is something sent
implicitly like a typing message or a receipt
This checks if there is an active sender state using the given ratchet
key, for use with decryption error messages. In this case, the app may
choose to archive the current session, or take even stronger actions
such as fetching new prekeys for the recipient.
The app-visible change is that sealedSenderMultiRecipientEncrypt now
takes a SessionStore as well. Sessions will be looked up in bulk using
a new SessionStore API, 'loadExistingSessions' or
'getExistingSessions`. The registration ID is then loaded from each
session and included in the resulting SSv2 payload.
The implementation is a bit of a divergence from some other APIs in
libsignal-client in that the "look up in bulk" step is performed in
the Java, Swift, or TypeScript layer, with the resulting sessions
passed down to Rust. Why? Because otherwise we'd pass a list of
addresses into Rust, which would have to turn them back into a Java,
Swift, or TypeScript array to call the SessionStore method. This would
be (1) a bunch of extra work to implement, and (2) a waste of CPU when
we already /have/ a list of addresses in the correct format: the
argument to sealedSenderMultiRecipientEncrypt.
This is an example of "the boundaries between the Rust and
Java/Swift/TypeScript parts of the library don't have to be perfect;
they're internal to the overall product". In this case, we've taken
that a little further than usual: usually we try to make the
libsignal-protocol API as convenient as possible as well, but here it
had to be a bit lower-level to satisfy the needs of the app language
wrappers. (Specifically, callers need to fetch the list of
SessionRecords themselves.)
P.S. Why doesn't v1 of sealed sender include registration IDs? Because
for SSv1, libsignal-client isn't producing the entire request body to
upload to the server; it's only producing the message content that
will be decrypted by the recipient. With SSv2, the serialized message
the recipient downloads has both shared and per-recipient data in it,
which the server must assemble from the uploaded request. Because of
this, SSv2's encrypt API might as well produce the entire request.
Registration IDs are used to detect if a device ID has been reused,
since the new device will (with high probability) use a different
randomly-generated registration ID from the old one. The server should
be able to validate this for SSv2 like it does for SSv1, though the
handling of this for SSv1 is in the various apps.
We still encode the "current" version in the message version byte, but
the part that the receiver will check is now based on the session's
original message version rather than the "current" version in the
sender. (Note that these are the /same/ version right now, so this
change won't have any effect on the current wire format.)
This matches the behavior of SignalMessage and PreKeySignalMessage.
The parameters for these constructors cannot be chosen correctly in
isolation; messages always need to be created as part of a session.
The Node APIs have been renamed with leading underscores rather than
removed because we *did* have tests that explicitly constructed
messages just to test that they faithfully preserve information. In
this case the parameters are plausible values but not used for
anything.
This was MessageCounterError in libtextsecure; it's an "error" in that
it interrupts processing of an individual message, but that message
is then be discarded in practice.
Within a new 'Errors' module, we have a base class that indicates this
is a strongly-typed error, and an enum to identify what kind of error
it is and thus what extra properties it might have. TypeScript's type
narrowing support make this possible to do safely as long as all
instances of the base class do in fact have the extra properties that
match their code (and do not have an invalid code).
To expose this to Rust (via Neon):
- After loading the Rust library into Node, set an 'Errors' property
with the relevant error types on the module object.
- Whenever a bridge_fn produces an error, pass it to a new
SignalNodeError::throw API along with the 'this' object, which is
assumed to have to be the object with the 'Errors' property.
This is a little less tidy than how we do Java exceptions, but it
comes from not having access to the error classes by some kind of
absolute name. Alternate approaches considered include:
- Use an initialized-once global. Downside: would not work if you ever
had more than one Node engine live in a process, or quit and restarted
it.
- Store the errors on the global object under some long, complicated
key (like "org.signal.libsignal-client.Errors"). Downside: pollutes
the global object.
- Generate the base class using Neon instead of writing it in
TypeScript. Downsides: inconvenient, difficult to maintain, harder to
use /from/ TypeScript.
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
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.
This slipped in the original translation to Rust, but it doesn't
matter in practice because both nibbles of the version byte have had
the same value for a long time.
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)
Specifically, use 'NativeImpl' to refer to the run-time bindings
(instead of 'SC'), and 'Native' to refer to the TypeScript module for
those bindings (instead of 'SignalClient'). This makes
compile-time diagnostics clearer, since the overall Node package is
named 'signal-client'.
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.
This will be necessary for async, which needs to keep the boxed Rust
values alive. (Node N-API only allows keeping JS objects alive; boxed
values don't count on their own.)
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.
This collects doc comments of the form "ts: <some TS declaration>",
which can be written manually *or* generated by the various "bridge"
macros. If the declaration looks like a function, it also does some
substitution of Rust types for TypeScript types, to make
autogeneration easier.
This only works on functions using the macros in libsignal-bridge; for
anything else we'll keep using neon::ModuleContext::export_function
manually, at least for now.
This allows the Desktop client to add this module as a dependency and
have its existing build process take care of building it against the
correct version of Electron. (Within the repo, `yarn build` calling
`electron-build-env` is still necessary; a plain `electron-rebuild`
seems to get confused.)
