For N-API builds this shouldn't matter, but currently the latest Node
headers don't let us build correctly on Windows, so we need to pin
to *something*.
Previously all APIs were available through the top-level index.ts, but
now the zkgroup APIs are in their own module. To access that in the
old packaging required writing
import * from '@signalapp/signal-client/node/dist/zkgroup'
This commit moves the package root into the node/ directory to
eliminate the 'node/' component, then adds a top-level, precompiled
zkgroup.js/.d.ts so that clients can use
import * from '@signalapp/signal-client/zkgroup'
This will be used to build a "testable" signal-client-java.jar that
includes native libraries for macOS and Windows in addition to Linux.
This is something zkgroup already has; in particular it allows
developers working on the server to use the zkgroup APIs even if they
run macOS or Windows on their individual machines.
- 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
Based on the fuzzing input, this simulates message sends and receives,
out-of-order delivery, dropped messages, and session resets, solely to
find bugs in happy-path interaction between two clients.
This will run the prepare_command specified by the podspec, which
means it will try to build both simulator and device versions of
libsignal-ffi. This also means we don't need the separate "Build Rust
for iOS" test.
Updated the following crates to resolve duplication of cfg-if,
which is a macro-only crate anyway.
- backtrace
- getrandom
- log (relaxed the version on it as well)
- polyval (still not at latest because it uses a newer cpuid-bool than
sha2 does)
- sha2
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.
- Verify its correctness with build_ffi.sh --verify-ffi
- Regenerate with build_ffi.sh --generate-ffi
This simplifies the header search logic for both SwiftPM and
CocoaPods, as well as saving on build time by avoiding cbindgen.
The tweak to cbindgen.toml to prefer typedef-based structs and enums
is sidestepping an incompatibility between cbindgen 0.15.0 (which
GitHub has installed) and 0.16.0 (which allows reusing a release build
directory as well as a debug one).
We're not actually logging anything yet, but this will let us do so.
The logging is initialized using a static constructor so that clients
of SignalCoreKit don't have to do any additional setup. This requires
an ObjC file instead of a Swift one. (When running as a Swift package,
logs will just go to stderr via NSLog.)
