oci-zero 0.0.1

A no-std, allocation-free streaming core for OCI registries
Documentation
  • Coverage
  • 100%
    1 out of 1 items documented0 out of 0 items with examples
  • Size
  • Source code size: 18.2 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 84.9 kB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 3s Average build duration of successful builds.
  • all releases: 6s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • no-std-rs/oci-zero
    1 2 0
  • crates.io
  • Dependencies
    • —
  • Versions
  • Owners
  • pawelchcki

oci-zero

CI crates.io docs.rs

oci-zero aims to provide bounded-memory building blocks for accessing and unpacking content from remote Open Container Initiative (OCI) registries.

[!WARNING] Work in progress: oci-zero is not functional yet. Version 0.0.1 only establishes the project constraints and roadmap; it does not implement an OCI client or expose a usable public API.

Goals

  • Remain no_std and allocation-free by default.
  • Parse OCI descriptors, manifests, indexes, and registry responses incrementally, using caller-owned buffers and borrowed data.
  • Drive the OCI Distribution protocol through a caller-provided transport, without requiring a particular HTTP client, TLS stack, executor, or runtime.
  • Verify content digests while blobs are streamed from a registry.
  • Unpack image layers incrementally into a caller-provided sink, with bounded memory use and explicit handling for path safety and OCI whiteouts.
  • Define a pluggable metadata store that can operate without a heap or a filesystem.
  • Add optional alloc and std convenience adapters later without weakening the allocation-free core.

Design direction

The core APIs will favor borrowed values, fixed-capacity caller-owned buffers, visitors, and streaming source/sink traits. Network access, persistent storage, decompression, and platform integration will be supplied by applications or by optional adapter crates and features.

The intended implementation order is:

  1. Streamed parsing for the OCI metadata needed by registry operations.
  2. Transport-independent registry request and response state machines.
  3. Digest verification and streamed layer unpacking.
  4. A no-allocation metadata-store interface and reference backends.
  5. Optional ergonomic adapters for environments with alloc or std.

Compatibility

The minimum supported Rust version is 1.75. The default feature set is empty, and the core crate is expected to compile for targets that do not provide the Rust standard library.

License

Licensed under either of

at your option.