Fix a bunch of issues revealed by the upgraded clippy
- update UUID library for improved uuid! parser macro
- make #[cfg(test)] block the last thing in a file
- call .to_string() instead of format! without interpolation
- use infallible conversion instead of try_into().expect
- remove redundant "Error" suffix from enum variant names
- remove unused type
Previously we had the feature off but listed the dependency on
pqcrypto-kyber as non-optional, which was wasted work.
Note that the two versions of pqcrypto-kyber don't actually coexist
today! This should be treated as an API proof-of-concept, much like
our Kyber768 wrapper.
Check that a Frame that contains a Recipient proto contains valid data.
This adds validation for the `destination` field, which was previously
ignored.
Rust: UsernameError now has more cases. ProofVerificationFailure is
also split off into its own error type, separate from structural
username errors.
Java: Subclasses of BadDiscriminatorException have been added.
Swift: Some error codes have been renamed and others have been added.
TypeScript: Some error codes have been renamed and others have been
added. Discriminator errors are now proper LibSignalErrors.
This applies the NicknameLimits that were previously only checked in
Username::candidates_from, in addition to validating other aspects of
the username.
When groups of arguments are used together, it seems like it makes sense
to put them in a single struct and include the struct as a field wrapped
in an Option with a flatten annotation at the top level. Unfortunately,
there is a bug in clap that pevents this from working as intended. This
patch pushes the optionality down at the cost of making the handling
code more verbose.
Add an executable target that reads backup files from disk or from stdin (by
buffering the contents in memory to allow seeking), decrypts the contents if
keys are provided, validates, and prints the output if requested.
The scalars associated with these nicknames would be out of range of
the Ristretto group's prime order, meaning curve25519_dalek's Scalar
won't be able to hold them. Previously the value silently wrapped
around to the start of the group, but that would conflict with a
shorter nickname's scalar.
...as well as related types Aci, Pni, ServiceId,
ServiceIdFixedWidthBinaryBytes, ServiceIdKind, and DeviceId.
...so that zkgroup and libsignal-net don't have to depend on
libsignal-protocol (and indirectly on Kyber).
The types are still exported from libsignal-protocol, so this is not a
source-breaking change.
ProtocolAddress is still defined as a (String, DeviceId) pair; a
switch to (ServiceId, DeviceId) will probably still happen in the
future, but not in this commit.
This credential is issued by the group server and presented to the
chat server to prove that the holder is a member of *some* group with
a known list of people. This can be used to replace the access key
requirement for multi-recipient sealed sender sends.
This uses the Rayon library to perform a MapReduce-like operation of
computing key material on recipients and folding them together into
intermediate buffers, with one final collection step at the end. As
written this uses Rayon's default thread pool, which will be lazily
initialized with one worker thread per logical core. We're not trying
to share thread pools with either libsignal-net's tokio contexts,
RingRTC's dedicated threads, or a platform-specific work queue like
iOS's Dispatch; let's keep things simple for now.
As a downside, the code now has to fetch all of the recipients'
identity keys up front, since it's not guaranteed that loading from
the IdentityKeyStore is thread-safe. However, the significant
improvement in wall time spent generating key material for large
recipient lists on even a dual-core system makes this worth it.
This takes advantage of the fact that multiple devices for the same
user will have the same identity key and therefore will use the same
per-recipient SSv2 data anyway.
This commit also enforces (on the client send side) that device IDs
are in the range 1..=127 for destinations of a SSv2 message.
- Ensure positive, unique (signed_)pre_key_id values.
- Limit archiving more strictly based on sum of me/them.archive_count.
Co-authored-by: Jonathan Moody <103143855+moodyjon@users.noreply.github.com>
While neither Oracle's JRE nor Android's misbehaves if you go over
your limit of local references, it may result in the local frame
growing arbitrarily large. We don't want that.
Rust's usize serves the same purpose as both size_t and uintptr_t in
C, but for our uses it's always a buffer length or capacity rather
than something specifically the same size as a pointer or machine
register, so size_t is more accurate.
Swift, then, imports size_t as its currency type Int, even though
size_t is unsigned in C, because no buffer can actually fill up all of
memory. Swift, like Rust, doesn't have implicit numeric conversions,
so importing size_t as Int was deemed more useful in practice.
And use usize for size_t:
- They're always equivalent in practice.
- When we're actually using it as a memory size, we're talking about
the size of Rust objects, so usize is more accurate anyway.
This eliminates the use of the libc crate in the bridge layer. We
still use libc for time_t in attest and device_transfer, to interact
with BoringSSL.
