The main benefit of this is not our *own* type-checking; it's that
mypy will error out if you try to use a too-new Python API. And in
fact, we were already relying on Python 3.9 and didn't realize.
check_code_size.py works with JSON, so it still uses Any a fair bit.
This parallels the exiting libsignal-jni crate but exports functions from
libsignal-bridge-testing instead of libsignal-bridge. The crate is compiled as
a separate shared object that is included in the published libsignal package,
but which can be excluded at Android packaging time.
This allows enabling debug- and trace-level logs even in a release
build. (This also means the job of filtering *out* those logs has been
moved up to build_ffi.sh, where previously it was specified in the
leaf crate's Cargo.toml.)
This (1) actually works on iOS and Android, and (2) will likely be
more full-featured and better-supported going forward. But it does
mean plugging one system's certificate verifier (rustls) into
another's TLS implementation (BoringSSL). Still, having *all* of
rustls used alongside BoringSSL would be redundant.
Some lines just have "src/foo.rs" in their debug info, for unclear
reasons. We could collect them into an "unknown crates" bucket, but
that isn't very useful either. This tweak just prevents them from
being collected into a line with no label.
The new version introduced a couple changes that are reflected here:
- Rename override_git_commit -> override-git-commit in about.toml since
that's now the canonical spelling.
- Regenerate the license list since a bug was fixed that changed the
semantics of the count.
Also pin the version in our documentation and in the script to prevent
differences in behavior depending on when cargo-about was installed on
developer machines.
Previously this didn't compose correctly with `--duplicates` (`-d`),
but now it prunes out dependencies in proc-macros just like we already
were for non-"normal" dependencies (build and dev), allowing us to
maintain our focus on code size.
While here, prefer long forms of flags for more readable code, and
improve the comments around the dependencies we can't avoid
duplicating.
libsignal-bridge uses linkme to make a big list of all functions
it's going to expose to Node. More recent linkme versions fix
issues where that list wasn't being preserved by linkers.
This manifested as a CI failure on Windows.
Rather than building the Rust parts of libsignal as part of `pod
install`, fetch them from build-artifacts.signal.org. This requires
adding
ENV['LIBSIGNAL_FFI_PREBUILD_CHECKSUM'] = '...'
to the consuming Podfile. The referenced archives are downloaded to
~/Library/Caches/org.signal.libsignal, and are unarchived as part of
the build. (The archives are outside the build directory so that a
clean build does not require a new download.)
Building with LibSignalClient as a local pod is still supported; in
that case everything will refer to the local target/ directory
instead. Use swift/build_ffi.sh to build as usual.
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.
Rather than have a separate "testable" artifact, always include Mac
and Windows versions of libsignal_jni.so when publishing
signal-client-java *and* libsignal_server (though not when just
building locally).
Also, finally attach these tasks to the correct step (processResources
rather than compileJava).
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'
- 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
