[PR #3139] [CLOSED] fix(rust): accept documented cargo-auditable format revisions 0 and 8 #5636

Closed
opened 2026-10-31 01:08:10 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3139
Author: @Dragolone
Created: 10/14/2026
Status: ❌ Closed

Base: main ← Head: fix/rust-auditable-format-revisions


📝 Commits (2)

  • 94b6393 fix(rust): accept documented cargo-auditable format revisions 0 and 8
  • bcb56c1 Merge remote-tracking branch 'origin/main' into HEAD

📊 Changes

3 files changed (+25 additions, -5 deletions)

View changed files

📝 src/domain/rust/rustBinary.ts (+3 -2)
📝 src/rust/RustAuditableReader.test.ts (+17 -0)
📝 src/rust/RustAuditableReader.ts (+5 -3)

📄 Description

Summary

inspect_rust_binary reads the cargo-auditable .dep-v0 section, but the reader and the report schema admit only "format": 1. cargo-auditable writes "format": 8 when Cargo's SBOM precursor supplies the dependency tree (CARGO_BUILD_SBOM=true cargo +nightly auditable build -Z sbom, see cargo-auditable/src/sbom_precursor.rs). For such a binary the whole call fails with "Unsupported cargo-auditable format version 8", and no package list is returned.

auditable-serde documents the format field of VersionInfo with three known revisions: 0 (or the field omitted), 1, and 8. All three use the same JSON package schema, and they differ only in how the dependency data was collected.

No issue is linked: I searched open issues and PRs for "auditable", "cargo-auditable", "sbom", "RustAuditableReader" and "inspect_rust_binary" and found no report. No open PR touches the changed files.

Problem and expected behavior

Smallest trigger: a .dep-v0 section whose JSON is {"format":8,"packages":[{"name":"sample","version":"0.1.0","source":"local","root":true}]}. The base refuses it as unsupported. Expected: the packages are read and format_version reports 8.

Change and scope

RUST_AUDITABLE_FORMAT_VERSION = 1 becomes RUST_AUDITABLE_FORMAT_VERSIONS = [0, 1, 8], used by both the section reader and rustAuditableMetadataSchema.format_version. An explicit 0 now reports format_version: 0; an omitted field still reports null.

Not included: undocumented revisions are still refused as unsupported (the existing "rejects an unknown format" test is unchanged). auditable-serde says an unknown revision may be treated as the highest known preceding one; whether REA should adopt that is a separate decision.

Contribution scope: a compatibility fix in an existing reader; a maintainer scope decision is not applicable.

Contract and boundary impact

  • Semantic owner and earliest changed stage: parseDocument in src/rust/RustAuditableReader.ts and rustAuditableMetadataSchema in src/domain/rust/rustBinary.ts.
  • Contribution scope fit and linked maintainer decision: in scope; not applicable.
  • CLI and MCP/tool-catalog contract: format_version in the inspect_rust_binary output may now be 0, 1, 8 or null instead of only 1 or null.
  • Provider, bridge, target-format, or platform compatibility: Rust binaries built with cargo-auditable's SBOM-precursor path, or carrying an explicit "format": 0.
  • Evidence, artifact, provenance, or reconstruction contract: none beyond the widened format_version value.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: the generated catalog's output schema for inspect_rust_binary reflects the widened literal; no committed file changes.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: src/rust/RustAuditableReader.test.ts — "reads documented format revision 0" and "reads documented format revision 8". Each checks format_version and root_package_index on the reader output and parses it with rustAuditableMetadataSchema, so both the reader and the schema are covered.
  • Base reproduction or other evidence: executed. On the base both cases fail with RustAuditableFormatFailure: Unsupported cargo-auditable format version 0 / … 8. The meaning of revisions 0, 1 and 8 is taken from the VersionInfo::format documentation in auditable-serde/src/lib.rs (source-derived).
  • User-visible CLI/MCP output (if applicable): not captured.
  • Remaining proof gaps: no binary built with nightly -Z sbom was added as a fixture.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

  • npx vitest run src/rust/RustAuditableReader.test.ts on the base — 2 failed (the new cases), 11 passed.

  • npx vitest run src/rust tests/boundary/rust tests/boundary/mcp/rustBinaryMcp.test.ts src/contracts/toolEffects.test.ts with the fix — 4 files, 31 tests passed.

  • npx vitest run src/application/rust — 1 file, 5 tests passed.

  • npm run build:cached then npx vitest run tests/acceptance/rustBinaryCli.test.ts — 3 tests passed.

  • npx vitest run tests/boundary/mcp/toolSchemaValidity.test.ts — 13 tests passed.

  • npx tsc --noEmit — 0 errors.

  • npx oxlint and npx oxfmt --check on the changed files — clean.

  • npm run verify:module-boundaries — passed.

  • pre-push hook (deps check, typecheck, lint) — passed.

  • After rebasing onto main 583008852: npx vitest run src/rust src/application/rust tests/boundary/rust tests/boundary/mcp/rustBinaryMcp.test.ts src/contracts/toolEffects.test.ts — 36 tests passed; npx tsc --noEmit — 0 errors.

Compatibility, safety, and release

  • Breaking changes or migration steps: none; existing format 1 and omitted-field results are unchanged.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: read-only parsing; the existing size and inflate-ratio limits still apply.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/3139 **Author:** [@Dragolone](https://github.com/Dragolone) **Created:** 10/14/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/rust-auditable-format-revisions` --- ### 📝 Commits (2) - [`94b6393`](https://github.com/morluto/rea/commit/94b6393b2412d8e3f9bde1d0ac9a9cc052138377) fix(rust): accept documented cargo-auditable format revisions 0 and 8 - [`bcb56c1`](https://github.com/morluto/rea/commit/bcb56c1e539482a2044141677f869aca9ae59fab) Merge remote-tracking branch 'origin/main' into HEAD ### 📊 Changes **3 files changed** (+25 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/rust/rustBinary.ts` (+3 -2) 📝 `src/rust/RustAuditableReader.test.ts` (+17 -0) 📝 `src/rust/RustAuditableReader.ts` (+5 -3) </details> ### 📄 Description ## Summary `inspect_rust_binary` reads the cargo-auditable `.dep-v0` section, but the reader and the report schema admit only `"format": 1`. cargo-auditable writes `"format": 8` when Cargo's SBOM precursor supplies the dependency tree (`CARGO_BUILD_SBOM=true cargo +nightly auditable build -Z sbom`, see `cargo-auditable/src/sbom_precursor.rs`). For such a binary the whole call fails with "Unsupported cargo-auditable format version 8", and no package list is returned. auditable-serde documents the `format` field of `VersionInfo` with three known revisions: 0 (or the field omitted), 1, and 8. All three use the same JSON package schema, and they differ only in how the dependency data was collected. No issue is linked: I searched open issues and PRs for "auditable", "cargo-auditable", "sbom", "RustAuditableReader" and "inspect_rust_binary" and found no report. No open PR touches the changed files. ## Problem and expected behavior Smallest trigger: a `.dep-v0` section whose JSON is `{"format":8,"packages":[{"name":"sample","version":"0.1.0","source":"local","root":true}]}`. The base refuses it as unsupported. Expected: the packages are read and `format_version` reports 8. ## Change and scope `RUST_AUDITABLE_FORMAT_VERSION = 1` becomes `RUST_AUDITABLE_FORMAT_VERSIONS = [0, 1, 8]`, used by both the section reader and `rustAuditableMetadataSchema.format_version`. An explicit `0` now reports `format_version: 0`; an omitted field still reports `null`. Not included: undocumented revisions are still refused as unsupported (the existing "rejects an unknown format" test is unchanged). auditable-serde says an unknown revision may be treated as the highest known preceding one; whether REA should adopt that is a separate decision. Contribution scope: a compatibility fix in an existing reader; a maintainer scope decision is not applicable. ## Contract and boundary impact - Semantic owner and earliest changed stage: `parseDocument` in `src/rust/RustAuditableReader.ts` and `rustAuditableMetadataSchema` in `src/domain/rust/rustBinary.ts`. - Contribution scope fit and linked maintainer decision: in scope; not applicable. - CLI and MCP/tool-catalog contract: `format_version` in the `inspect_rust_binary` output may now be 0, 1, 8 or `null` instead of only 1 or `null`. - Provider, bridge, target-format, or platform compatibility: Rust binaries built with cargo-auditable's SBOM-precursor path, or carrying an explicit `"format": 0`. - Evidence, artifact, provenance, or reconstruction contract: none beyond the widened `format_version` value. - Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: the generated catalog's output schema for `inspect_rust_binary` reflects the widened literal; no committed file changes. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `src/rust/RustAuditableReader.test.ts` — "reads documented format revision 0" and "reads documented format revision 8". Each checks `format_version` and `root_package_index` on the reader output and parses it with `rustAuditableMetadataSchema`, so both the reader and the schema are covered. - Base reproduction or other evidence: executed. On the base both cases fail with `RustAuditableFormatFailure: Unsupported cargo-auditable format version 0` / `… 8`. The meaning of revisions 0, 1 and 8 is taken from the `VersionInfo::format` documentation in `auditable-serde/src/lib.rs` (source-derived). - User-visible CLI/MCP output (if applicable): not captured. - Remaining proof gaps: no binary built with nightly `-Z sbom` was added as a fixture. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npx vitest run src/rust/RustAuditableReader.test.ts` on the base — 2 failed (the new cases), 11 passed. - `npx vitest run src/rust tests/boundary/rust tests/boundary/mcp/rustBinaryMcp.test.ts src/contracts/toolEffects.test.ts` with the fix — 4 files, 31 tests passed. - `npx vitest run src/application/rust` — 1 file, 5 tests passed. - `npm run build:cached` then `npx vitest run tests/acceptance/rustBinaryCli.test.ts` — 3 tests passed. - `npx vitest run tests/boundary/mcp/toolSchemaValidity.test.ts` — 13 tests passed. - `npx tsc --noEmit` — 0 errors. - `npx oxlint` and `npx oxfmt --check` on the changed files — clean. - `npm run verify:module-boundaries` — passed. - pre-push hook (deps check, typecheck, lint) — passed. - After rebasing onto main 583008852: `npx vitest run src/rust src/application/rust tests/boundary/rust tests/boundary/mcp/rustBinaryMcp.test.ts src/contracts/toolEffects.test.ts` — 36 tests passed; `npx tsc --noEmit` — 0 errors. ## Compatibility, safety, and release - Breaking changes or migration steps: none; existing format 1 and omitted-field results are unchanged. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. - Package or release metadata impact: none. - Security, privacy, process, or containment review: read-only parsing; the existing size and inflate-ratio limits still apply. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:08:10 +00:00
Sign in to join this conversation.
No milestone
No project
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
morluto/rea#5636
No description provided.