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.
- Use displaydoc to stringify the errors, using the comments that were
already there. These go into the string descriptions for errors
exposed to the apps, which can be useful.
- Split PointDecodeError into its own type so that it's not exposed
generally.
- Bump the version to 0.9.0, mainly so it doesn't get confused with
the original repo.
- Use the poksho in this repo and our custom 3.0.0-lizard2 branch of
curve25519-dalek (instead of a 2.0.0-based one).
- Bump the sha2 dependency to match curve25519-dalek 3.0.
- Remove the reference to the crate's ffi module.
With this, the tests pass and the benchmarks run.
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.
- cargo update
- But stay on our fork of curve25519-dalek (pinned at 3.0.0)
- Update x25519-dalek from 1.0 to 1.1 (instead of 1.2) to stay
compatible with curve25519-dalek
- Update cpufeatures to 2.1 to match our dependencies
- Note that updating picky* resulted in more duplicate crates (rand*)
- Pin num-bigint-dig to a build that supports Cargo's -Zbuild-std,
because xargo + autocfg has stopped working with the new toolchain
- Remove xargo in favor of -Zbuild-std
Signal has a fork of curve25519-dalek to add some features that are
used by zkgroup. However, libsignal-protocol and poksho don't use
those features directly, and thus they don't depend on our fork
specifically. Anyone outside of Signal using libsignal-protocol can
thus use the standard curve25519-dalek and avoid building it twice.
Signal will continue using our fork thanks to the workspace patch in
the root Cargo.toml.
Additionally, remove all the passthrough features for customizing
curve25519-dalek; we don't use any of them, and clients can always
specify them directly.
This is overkill for most calls but multi-recipient messages require
potentially a lot of objects. The codegen is in the way of making a
surgical change at the moment so hitting it with a broad fix for
now. May return to add a conditional to the macro definition later.
- Drop our fork of Neon now that our changes have been integrated
- Adopt rename of EventQueue to Channel
- Add a napi-6 feature to signal-neon-futures to make it easier to test
under the configuration we're actually shipping
Both futures::executor::block_on and our own expect_ready were being
used to resolve futures that were, in practice, known to be
non-blocking. FutureExt::now_or_never handles that case more lightly
than block_on and more uniformly than expect_ready.
This lets us drop the dependency on the full 'futures' crate down to
just futures_util, which should help with compile time.
