Add OCI registry to Bencher API server

[epompeii]

This changeset adds an OCI compliant registry to the Bencher API server.
Bencher Cloud will direct folks to use registry.bencher.dev to push images up.
Images will be pulled by the forthcoming Bencher Bare Metal Runner.

[github-actions]

Bencher Report

Branch	u/ep/oci
Testbed	ubuntu-22.04

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

• Latency (nanoseconds (ns))

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

Click to view all benchmark results

Benchmark	Latency	microseconds (µs)
Adapter::Json	📈 view plot ⚠️ NO THRESHOLD	3.78 µs
Adapter::Magic (JSON)	📈 view plot ⚠️ NO THRESHOLD	3.88 µs
Adapter::Magic (Rust)	📈 view plot ⚠️ NO THRESHOLD	27.99 µs
Adapter::Rust	📈 view plot ⚠️ NO THRESHOLD	2.89 µs
Adapter::RustBench	📈 view plot ⚠️ NO THRESHOLD	2.89 µs

🐰 View full continuous benchmarking report in Bencher

[github-actions]

🤖 Claude Code Review

PR: #654
Base: devel
Head: u/ep/oci
Commit: e24c60e140cfd2f320a016c0fdfcc00043ded400

---

Now I have enough context to write a comprehensive review.

Pull Request Review: OCI Registry Implementation

Summary

This PR adds OCI (Open Container Initiative) Distribution Specification compliant registry functionality to Bencher as a Plus feature. It includes ~9,800 lines of new code across 83 files.

Positive Aspects

1. Well-structured architecture: Clean separation between API layer (plus/api_oci), storage layer (plus/bencher_oci_storage), and authentication (lib/api_auth/src/oci).

2. Comprehensive test coverage: Integration tests for base, blobs, manifests, tags, referrers, and uploads (6 test files with extensive test cases).

3. Dual storage backends: Supports both S3 (production) and local filesystem (development), with proper abstraction.

4. OCI spec compliance: Implements the full OCI Distribution Spec including the referrers API.

5. Rate limiting: Properly applies rate limiting for both authenticated and unauthenticated users.

6. Documentation: Good inline documentation and updated server config docs in multiple languages.

Issues & Concerns

Security

1. Pull access restricted to admins only (lib/api_auth/src/oci/mod.rs:122-130):

   if !auth_user.is_admin(&context.rbac) {
       return Err(HttpError::for_client_error(..., "Only server admins can pull OCI images"));
   }

   This seems overly restrictive. Users who pushed images may need to pull them. Consider allowing pull access for users with at least View permission on the project.

2. Unauthenticated push to unclaimed projects (plus/api_oci/src/auth.rs:194-215): While this enables the workflow of pushing first and claiming later, it could lead to abuse. Ensure rate limiting is sufficient to prevent resource exhaustion.

3. CORS with wildcard origin (plus/api_oci/src/blobs.rs:133):

   .header(http::header::ACCESS_CONTROL_ALLOW_ORIGIN, "*")

   While this may be needed for OCI client compatibility, consider documenting this security trade-off.

Code Quality

1. Missing #[expect] justifications: Several #[expect(clippy::map_err_ignore)] and #[expect(clippy::too_many_lines)] are used correctly with reason strings, which is good.

2. Path traversal consideration (plus/bencher_oci_storage/src/local.rs): The local storage uses user-provided repository names to construct file paths. While ProjectResourceId validation should prevent path traversal, verify that all path components are sanitized:

   fn repository_dir(&self, repository: &ProjectResourceId) -> PathBuf {
       self.base_dir.join(repository.to_string())
   }

   The ProjectResourceId type should prevent malicious input like ../../../etc/passwd but this warrants verification.

3. S3 chunk cleanup on error paths (plus/bencher_oci_storage/src/storage.rs): The cleanup_upload function ignores deletion errors, which is acceptable for cleanup, but errors are not logged.

Performance

1. Streaming blob downloads: Good use of streaming bodies (BlobBody, S3BlobBody, LocalBlobBody) to avoid loading large blobs into memory.

2. Chunk-based upload storage: The O(1) chunk append strategy for S3 (plus/bencher_oci_storage/src/storage.rs:312-335) is well-documented and efficient.

3. Background stale upload cleanup: Good pattern - cleanup runs in a spawned task without blocking upload operations.

Compliance with CLAUDE.md

1. Feature gating: Correctly uses #[cfg(feature = "plus")] for Plus features.

2. Lint expectations: Uses #[expect(...)] instead of #[allow(...)] as required.

3. OpenAPI changes: services/api/openapi.json updated with new OCI endpoints.

4. Recommended verification: Run cargo check --no-default-features and cargo gen-types to verify the API changes compile correctly without Plus features.

Minor Issues

1. Unused import warning suppression (plus/bencher_oci_storage/src/lib.rs:13-16):

   #[cfg(test)]
   use reqwest as _;

   This is a valid pattern for dev-dependencies.

2. Hardcoded OCI token TTL (lib/api_auth/src/oci/mod.rs:34): Consider making this configurable via the config file.

Recommendations

1. Review pull access policy: The admin-only restriction for pull seems too restrictive for typical use cases.

2. Add logging for cleanup errors: In cleanup_upload, log failures at debug level for troubleshooting.

3. Verify cargo gen-types: Per CLAUDE.md, since the API has changed, ensure cargo gen-types has been run.

4. Consider adding conformance tests: The plus/bencher_oci_storage/tests/conformance.rs exists but verify it runs the OCI conformance test suite.

Verdict

This is a substantial, well-architected addition. The main concerns are around the pull access restriction policy and ensuring path traversal protection is robust. The code quality is high with good documentation and test coverage.

---

_{Model: claude-opus-4-5-20251101}