public/steve
6
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Add a minimal UniFFI façade for steve-sdk #11

New issue
Closed
opened 2026-08-13 09:11:41 +00:00 by Ghost · 1 comment
Ghost commented 2026-08-13 09:11:41 +00:00 (Migrated from codeberg.org)
Copy link

Goal

Add a thin UniFFI wrapper so Swift can use the full current steve-sdk, including X25519 and XWING-DRAFT10.

Rust remains responsible for HTTP, attestation, protocol state, cryptography, session keys, and Tokio execution.

Scope

Create a separate steve-sdk-uniffi crate exposing:

  • Client configuration, application context, and timeouts
  • Pinned PCR profiles and caller-owned TOFU storage
  • Explicit X25519 or XWING-DRAFT10 selection
  • Attestation verification and session rotation
  • Protected requests and responses
  • Attestation metadata and PCR trust status
  • Stable, distinguishable SDK errors

Expose TOFU persistence through a Swift-implemented UniFFI callback:

loadOrInsert(key, observedPcrs) -> inserted | existing(storedPcrs)

This stores PCR trust records only. Cryptographic keys and derived secrets remain ephemeral and Rust-owned.

Semantic parity is required, not literal Rust API parity. Rust-specific APIs such as reqwest::ClientBuilder, generic JSON helpers, and duplicate convenience methods do not need FFI equivalents.

Deliverables

  • steve-sdk-uniffi workspace crate
  • Generated Swift source, C header, module map, and host static library
  • Wrapper-owned Tokio runtime
  • Rust tests for both PCR policies, both suites, error mapping, rotation, and protected requests
  • Minimal macOS Swift smoke test covering:
    • One pinned X25519 request
    • One TOFU XWING-DRAFT10 request
    • Attestation results and session rotation
  • Concise build and usage documentation

Acceptance criteria

  • All current SDK protocol and security capabilities are reachable from Swift.
  • Both suites complete protected requests with no negotiation or fallback.
  • TOFU storage remains atomic, durable, caller-owned, and fail-closed.
  • Existing steve-sdk tests pass.
  • Generated bindings compile, link, and pass the Swift smoke test.

Out of scope

  • Handwritten Swift SDK or application
  • iOS or Xcode integration
  • XCFramework, SwiftPM, or CocoaPods packaging
  • Keychain or Secure Enclave integration
  • Platform KEM providers or CryptoKit substitution
  • Protocol changes or persistent session keys

A later issue may investigate a platform KEM provider and Secure Enclave support after proving compatibility with the existing XWING-DRAFT10 test vectors. V1 keeps the current ephemeral Rust KEM implementation unchanged.

## Goal Add a thin UniFFI wrapper so Swift can use the full current `steve-sdk`, including `X25519` and `XWING-DRAFT10`. Rust remains responsible for HTTP, attestation, protocol state, cryptography, session keys, and Tokio execution. ## Scope Create a separate `steve-sdk-uniffi` crate exposing: - Client configuration, application context, and timeouts - Pinned PCR profiles and caller-owned TOFU storage - Explicit `X25519` or `XWING-DRAFT10` selection - Attestation verification and session rotation - Protected requests and responses - Attestation metadata and PCR trust status - Stable, distinguishable SDK errors Expose TOFU persistence through a Swift-implemented UniFFI callback: ```text loadOrInsert(key, observedPcrs) -> inserted | existing(storedPcrs) ``` This stores PCR trust records only. Cryptographic keys and derived secrets remain ephemeral and Rust-owned. Semantic parity is required, not literal Rust API parity. Rust-specific APIs such as `reqwest::ClientBuilder`, generic JSON helpers, and duplicate convenience methods do not need FFI equivalents. ## Deliverables - `steve-sdk-uniffi` workspace crate - Generated Swift source, C header, module map, and host static library - Wrapper-owned Tokio runtime - Rust tests for both PCR policies, both suites, error mapping, rotation, and protected requests - Minimal macOS Swift smoke test covering: - One pinned `X25519` request - One TOFU `XWING-DRAFT10` request - Attestation results and session rotation - Concise build and usage documentation ## Acceptance criteria - All current SDK protocol and security capabilities are reachable from Swift. - Both suites complete protected requests with no negotiation or fallback. - TOFU storage remains atomic, durable, caller-owned, and fail-closed. - Existing `steve-sdk` tests pass. - Generated bindings compile, link, and pass the Swift smoke test. ## Out of scope - Handwritten Swift SDK or application - iOS or Xcode integration - XCFramework, SwiftPM, or CocoaPods packaging - Keychain or Secure Enclave integration - Platform KEM providers or CryptoKit substitution - Protocol changes or persistent session keys A later issue may investigate a platform KEM provider and Secure Enclave support after proving compatibility with the existing `XWING-DRAFT10` test vectors. V1 keeps the current ephemeral Rust KEM implementation unchanged.
Ghost commented 2026-08-18 08:29:12 +00:00 (Migrated from codeberg.org)
Copy link

done 00d363c37b

done 00d363c37b
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/bump-bootproof-es384
fix/atomic-metadata-publication
docs/canonical-repository-notice
feat/forge-migration
feat/steve-v2-parsing-hardening
add-license
feat/pcr-policies-js-wasm
feat/swift-uniffi-integration
feat/fail-closed-plaintext
feat/rust-sdk-update
feat/xwing-key-exchange
anton/steve-proxy-mvp
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
public/steve#11
No description provided.