# teaclave-crates

**Repository Path**: mirrors_apache/teaclave-crates

## Basic Information

- **Project Name**: teaclave-crates
- **Description**: A collection of ported and TEE-tailored Rust dependencies.
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-09-04
- **Last Updated**: 2026-06-27

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Teaclave Dependency Crates

[![License](https://img.shields.io/badge/license-Apache-green.svg)](LICENSE)
[![Homepage](https://img.shields.io/badge/site-homepage-blue)](https://teaclave.apache.org/)

This repository hosts Rust crates maintained by the [Teaclave community](https://github.com/apache/teaclave). 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](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](https://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:

| Phase       | Description                                                                 |
|------------|-----------------------------------------------------------------------------|
| Development| Crates must be ported from the latest stable upstream versions on crates.io.|
| Review     | Each crate undergoes a security review focused on diffs from the upstream.  |
| Testing    | TEE-specific test suites must pass before merging.                          |
| Publishing | Stable versions are published to crates.io as `teaclave-*`.                 |
| Iteration  | New upstream versions must follow the same process, replacing the old one.  |

- The repository includes only the **latest ported version** of each crate.
- [crates.io](https://crates.io) hosts all **published stable versions**.
- Users can depend on any published version using standard Cargo dependency syntax.