Upcoming work in `attest` requires additional X509 support, and swapping these libraries
is a negligible impact on binary size. This uses a fork of `cloudflare/boring`, as
we have some additions that haven’t yet been contributed upstream.
...which drops our dependency on Electron altogether. We originally
tested with electron-mocha to more closely resemble the Desktop app,
but libsignal-client doesn't actually use anything Electron-specific,
and because it uses N-API we don't have to sync up versions exactly
(and indeed we haven't been updating the Electron in this repo as
often as the Desktop app has taken new Electrons).
Two benefits of this: you can now run the tests on headless systems
(see the change to the CI script), and `yarn install` has less to
download.
Pros:
- Linux executors are cheaper on GitHub's CI, when running in the
private repository.
- Checks that the Swift package can still be built and tested on
Linux, even though that's not a primary goal.
Cons:
- Removed the code coverage report. It's possible to do this on Linux
as well, but we haven't been using this as a primary tool, and it's
still possible to check locally (particularly by running in Xcode).
The coverage of the Rust tests is more interesting anyway, and we
haven't had an automated report for *that*.
Neutral:
- Moved the SwiftLint run to the "Swift CocoaPod" job, since SwiftLint
isn't installed on GitHub's Linux images by default. Even though
"Swift CocoaPod" is the longest job at the moment and we may want to
shorten it, the SwiftLint action is quick anyway.
node-gyp-build should make sure that we don't build the Rust library
*again*, but if we do by accident, the tests should still run against
what we're going to submit, which is what's in the prebuilds/
directory.
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.
