Teaclave Dependency Crates

This repository hosts Rust crates maintained by the Teaclave community. These include ported and TEE-adapted dependencies designed for secure, memory-safe development in confidential computing environments.

Security note: every crate here is linked into the trusted side of a TEE application, so the whole repository is part of its consumers' Trusted Computing Base. See docs/security-model.md for the trust model, the diff-from-upstream review unit, and supply-chain guidance.

Purpose of This Repository

Adapting With Target-Dependent Security Primitives

While Teaclave SDKs aim to be as compatible with std as possible, some crates cannot be used out-of-the-box due to TEE-specific security constraints. This often requires additional effort to port or adapt existing crates—such as replacing randomness sources, handling untrusted filesystems, or accommodating different security assumptions.

Easing Upstream Integration Barriers

Ideally, we would upstream patches to add confidential computing support directly into the original crates. However, this depends on upstream maintainers' interest and alignment, which can be challenging—especially when the original crate was not designed with TEE support in mind.

This repository serves to:

• Demonstrate how crates can be adapted for TEE environments;
• Provide reusable versions that developers can depend on directly;
• Help developers learn from the diffs and port their own crates if needed.

Principles for Management

This repository supports two hosting approaches, selected per dependency and maintenance cost:

1. Patch bundle approach
   Keep a known upstream source snapshot and maintain Teaclave/TEE adaptation patches in this repository.
2. Full crate import approach
   Import the adapted crate source directly into this repository when a standalone crate copy is clearer or easier to maintain.

In practice, both approaches are valid and can coexist in the same repository based on actual needs.

Each adapted crate lives in its own directory at the repository root. The directory name encodes the hosting approach: a full crate import is named <crate>-<version>, while a patch bundle appends the pinned upstream base-commit, <crate>-<version>-<base-commit>, and contains *.patch files applied on top of that snapshot.

.
├── getrandom-0.2.16/          # full crate import (adapts the randomness source)
├── ring-0.17.14/             # full crate import (crypto)
├── libc-0.2.182-e879ee9/     # patch bundle: optee-*.patch over a pinned snapshot
└── rust-1.93.1-01f6ddf/      # patch bundle: Rust std/compiler patches for OP-TEE

Both approaches keep the TEE adaptation reviewable as a diff against pristine upstream:

• Full crate import — the commit history follows a two-step convention: a Download <crate> <version> from crates.io commit imports the unmodified upstream source (including .cargo_vcs_info.json, which records the upstream revision), and the following commit(s) apply the TEE port. The adaptation delta is therefore git diff <download-commit> HEAD -- <crate-dir>/.
• Patch bundle — the adaptation delta is the in-tree *.patch file, applied on top of the pinned Base-Commit upstream snapshot.

Each adapted crate is:

• Maintained in its own isolated subdirectory;
• Version-aligned with the corresponding upstream crate where possible;
• Published to crates.io under the teaclave-* namespace once it passes review.

For example, an adaptation of the ring crate would be published as teaclave-ring. Developers can add these crates directly in their Cargo.toml, and compare them with their upstream counterparts on crates.io.

The repository follows these principles:

• The repository includes only the latest ported version of each crate.
• crates.io hosts all published stable versions.
• Users can depend on any published version using standard Cargo dependency syntax.