Skip to content

bundle: expose trusted resolved XLS producer identity#61

Open
dank-openai wants to merge 1 commit into
mainfrom
dank-spr/structural-id-materializer
Open

bundle: expose trusted resolved XLS producer identity#61
dank-openai wants to merge 1 commit into
mainfrom
dank-spr/structural-id-materializer

Conversation

@dank-openai

@dank-openai dank-openai commented Jun 5, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Materialize xlsynth-crate and XLS from independent release or exact-revision pins.
  • Expose one validated producer-identity manifest through XlsArtifactBundleInfo.
  • Restrict authoritative identity to the paired generated download-only runtime and toolchain.
  • Preserve existing local and installed bundle modes when authoritative identity is not requested.

Problem Solved

Auto-SPO structural IDs need to record the producer revisions that actually supplied the XLSynth driver and XLS runtime. Caller-provided version strings or unrelated local binaries could otherwise describe one toolchain while executing another.

The generated bundle now carries a resolved identity sidecar produced and validated along the same materialization path as the driver and runtime artifacts.

Mental Model

For an archive-capable bundle:

typed xlsynth-crate pin + typed XLS pin
  -> generated download-only runtime/toolchain pair
  -> validated resolved identity sidecar
  -> XlsArtifactBundleInfo.resolved_identity

Exact XLS Git revisions are accepted only when they map to published XLS release artifacts. The trusted boundary protects the generated Bazel graph; replacing rules_xlsynth itself or overriding generated repositories remains outside the contract.

Validation

  • python3 -B -m unittest artifact_resolution_test.py - 65 tests
  • bazel test //:trusted_identity_boundary_test
  • bazel cquery @rules_xlsynth_selftest_xls_toolchain//:xlsynth-driver --output=label
  • buildifier -lint=warn -mode=check BUILD.bazel xls_toolchain.bzl trusted_identity_boundary_test.bzl

Stack:

⚠️ Part of a stack created by spr-multicommit. Do not merge manually using the UI - doing so may have unexpected results.

@dank-openai dank-openai marked this pull request as draft June 5, 2026 00:22
@dank-openai dank-openai requested a review from meheff June 5, 2026 00:34
@dank-openai dank-openai marked this pull request as ready for review June 5, 2026 00:34
## Summary

- Materialize xlsynth-crate and XLS from independent release or exact-revision pins.
- Expose one validated producer-identity manifest through `XlsArtifactBundleInfo`.
- Restrict authoritative identity to the paired generated download-only runtime and toolchain.
- Preserve existing local and installed bundle modes when authoritative identity is not requested.

## Problem Solved

Auto-SPO structural IDs need to record the producer revisions that actually supplied the XLSynth driver and XLS runtime. Caller-provided version strings or unrelated local binaries could otherwise describe one toolchain while executing another.

The generated bundle now carries a resolved identity sidecar produced and validated along the same materialization path as the driver and runtime artifacts.

## Mental Model

For an archive-capable bundle:

```text
typed xlsynth-crate pin + typed XLS pin
  -> generated download-only runtime/toolchain pair
  -> validated resolved identity sidecar
  -> XlsArtifactBundleInfo.resolved_identity
```

Exact XLS Git revisions are accepted only when they map to published XLS release artifacts. The trusted boundary protects the generated Bazel graph; replacing `rules_xlsynth` itself or overriding generated repositories remains outside the contract.

## Validation

- `python3 -B -m unittest artifact_resolution_test.py` - 65 tests
- `bazel test //:trusted_identity_boundary_test`
- `bazel cquery @rules_xlsynth_selftest_xls_toolchain//:xlsynth-driver --output=label`
- `buildifier -lint=warn -mode=check BUILD.bazel xls_toolchain.bzl trusted_identity_boundary_test.bzl`

pr:structural-id-materializer
@dank-openai dank-openai force-pushed the dank-spr/structural-id-materializer branch from 30c36eb to 548cde7 Compare June 5, 2026 01:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant