- Skip building for Catalyst in pull request testing, but make up for
it in the "Slow Tests".
- Update the README now that the Arm Mac simulator is a Tier 2 Rust
target.
- Remove workaround for one-time incompatibility with the Arm Mac
simulator.
(but only if there have been any changes)
For now this is just exercising the Docker build, but I think we
should put some of the CocoaPods testing in here too, if not more of
the regular pull request testing.
Implements (a subset of) Intel's DCAP attestation,
making heavy use of 'boring' for X509 and ECDSA.
Cds2Client is now ready for use!
Co-authored-by: Jordan Rose <jrose@signal.org>
Co-authored-by: Ravi Khadiwala <ravi@signal.org>
Update to a revision of BoringSSL that supports cross-compilation to
AArch64 for both Linux and Windows (from an x86_64 host of the same
OS), and provide the necessary environment variables for the Linux
cross-build.
In the past manually-run GitHub Actions could only be run from a
branch, so specifying a tag to build had to be done explicitly. That's
no longer true, so we can remove that field.
- Combine stable and nightly job definitions in the workflow file
- Build bins along with benches
- Use --all-features for tests and bins and Clippy, to make sure the
maximum amount of code is tested. (If we ever have code omitted when
a feature is turned on, we may want to add more test configuration.)
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.
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.)
