Bump uniffi from 0.24.3 to 0.32.0 - #191
Conversation
Bumps [uniffi](https://github.com/mozilla/uniffi-rs) from 0.24.3 to 0.32.0. - [Changelog](https://github.com/mozilla/uniffi-rs/blob/main/CHANGELOG.md) - [Commits](mozilla/uniffi-rs@v0.24.3...v0.32.0) --- updated-dependencies: - dependency-name: uniffi dependency-version: 0.32.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
uniffi 0.32's `uniffi-bindgen generate` requires an explicit --out-dir (it previously defaulted to the UDL's directory). Pass `--out-dir src` to preserve the original output location (src/uniffi/bindings/bindings.kt) that the subsequent copy step relies on.
![ev-vaultkeeper[bot]](https://avatars.githubusercontent.com/u/47702631?s=60&v=4){kind=small}
There was a problem hiding this comment.
uniffi 0.24.3 → 0.32.0 — review
Verdict: safe to merge. The bump compiles, the generated public Kotlin API is unchanged, and the one real breakage (the deploy script) is fixed in a commit I pushed to this branch.
Where uniffi is used
uniffi is a direct dependency of only kotlin-attestation-bindings (UDL-based: include_scaffolding! in lib.rs, generate_scaffolding in build.rs, and the uniffi-bindgen bin). The core crate and the node/python/wasm/swift bindings do not depend on uniffi, so this bump cannot affect them. Note the kotlin bindings are not built or tested in CI (lint-and-test.yml path filters exclude kotlin-attestation-bindings/**), which is why all PR checks are green regardless.
What I verified locally (uniffi 0.32)
- ✅
cargo build --lib -p kotlin-attestation-bindings— the cdylib compiles (the scaffolding generated from the UDL matches the Rust fn signatures). - ✅
cargo build --features=uniffi/cli --bin uniffi-bindgen— bindgen bin builds. - ✅
uniffi-bindgen generate --language kotlinproduces bindings with the same public API:attestConnection(cert: ByteArray, ...),attestEnclave(...),data class PcRs, and the same FFI symbol names (uniffi_bindings_fn_func_attest_*).
(FYI: a bare cargo build of the whole workspace fails on the uniffi-bindgen bin because uniffi::uniffi_bindgen_main is gated behind the cli feature — but this is pre-existing; the base branch fails identically. The real build paths from build-libs.sh are cargo build --lib and cargo run --features=uniffi/cli --bin uniffi-bindgen.)
Changelog review (0.24 → 0.32)
I read every release. None of the breaking changes affect this crate because it only exposes two free functions and a plain record — no objects/interfaces, traits, custom/external types, async, or callbacks. The only 0.32 change that could have mattered — [ByRef] bytes now mapping to &[u8]/a direct ByteBuffer — does not apply: the UDL uses plain by-value bytes, which still maps to Vec<u8>/ByteArray (confirmed in the regenerated bindings).
The one breakage — fixed & pushed
uniffi 0.32's uniffi-bindgen generate now requires --out-dir (it used to default to the UDL's directory). The current build-libs.sh call omits it and panics under 0.32. I pushed a commit adding --out-dir src, which preserves the original output location (src/uniffi/bindings/bindings.kt) that the following cp relies on.
Follow-up (handled automatically): stale checked-in bindings.kt
The committed src/uniffi/bindings/bindings.kt was generated by 0.24. Under 0.32 the regenerated file differs: contract version 22 → 30, new checksums, and Kotlin now uses JNA direct mapping. I deliberately did not commit the ~950-line regenerated artifact — it isn't consumed by any build in this repo and build-libs.sh (now fixed) regenerates + copies it into the Android SDK at deploy time. If the stale file were ever paired with a freshly-built 0.32 .so, it fails safely with an explicit UniFFI contract version mismatch: try cleaning and rebuilding error (no silent misbehavior). Recommend regenerating it on the next Android release (the fixed script does this).
Security / supply chain
- Socket scores uniffi 0.32.0 100/100 supply-chain and 100/100 vulnerability. The only Socket warning is an MPL-2.0 license policy flag on
uniffi_bindgen— this is not new (all uniffi crates have always been MPL-2.0) and it's a build-time dependency, not linked into the shipped cdylib (runtime usesuniffi_core). - New transitive crates in
Cargo.lock(rustix,tempfile,getrandom 0.3,wasip2,wit-bindgen,toml 0.9,askama 0.16,textwrap, dualthiserror1/2) are pulled in byuniffi_bindgen/uniffi_buildat build/codegen time, not into the runtime artifact. Nothing suspicious — all from crates.io with checksums. No runtime attack-surface increase.
1 participant
Bumps uniffi from 0.24.3 to 0.32.0.
Changelog
Sourced from uniffi's changelog.
... (truncated)
Commits
5c7b739chore: Releasec4ec9d8chore: Release7d647a8Benchmark tablesad9b725Pipeline IDs0f6a2bcAllow literal number suffix foruniffi::Enum(#2926)bc38ff4Merge pull request #2927 from bendk/bdk/push-komxvuvksmqu046d894Merging changes from 0.31.2 back to mainafd83b2Loosen toml semver for uniffi_macros418ab38add async support for ruby05b45b1chore: ReleaseDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)