Publish and verify signed SBOM and ABI release assets
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with docs/RELEASE_PROCESS.md and docs/SIGNING.md, then inspect scripts/release/generate-sbom.sh, the release workflow, ABI generation and baseline policy, and existing release-verification and draft-publication helpers. The acceptance criteria call for exact-tag provenance, verification of uploaded bytes and identity, failure cases, partial-publication retries, regression checks, and downstream instructions; completion means these checks pass while preserving source-archive behavior and signing boundaries.
Written by the indexing model from the issue text.
Description
Scope and ownership
Automate generation/selection, signing, verification, and publication of SBOM and ABI release assets. This is an engineering child of #687 and delegates the SBOM/ABI artifact-signing slice of #750. #750 retains broader signing/GA acceptance; #1154 retains maintainer GPG identity and operational validation; #1318 owns certificate-minting authority.
Discovery context
The 2026-09-22 post-0.70.0 triage reviewed released commit c353350232c35356b34085abf5780a2fcb81e80f. docs/RELEASE_PROCESS.md and docs/SIGNING.md explicitly describe SBOM/ABI release attachment as unautomated. Existing generators and drift gates exist, and the release workflow signs the source archive, but #687 has no separate attachment implementation owner. Architect and Critic agreed to this decomposition and explicit delegation from #750; it is not a second source-archive signing pipeline.
Implementation boundary
- Reuse
scripts/release/generate-sbom.sh, ABI generation/baseline policy, existing release verification, and draft-release publication helpers. - Tie SBOM formats and ABI manifests to the exact tag SHA and documented build/architecture profile; preserve the existing Linux x86_64 layout-manifest versus architecture-independent symbol policy.
- Publish checksums and verifiable artifact signatures, binding verification to the exact bytes and intended signing identity.
- Preserve existing source-archive signing behavior, immutable published assets, and safe partial-publication retry semantics.
- Preserve narrowly scoped signing permissions and resolve #1318's authority boundary before relying on an expanded signed-artifact release claim.
- Do not designate GPG keys, waive GA checks, publish a GA release, or invent new ABI support tiers.
Acceptance criteria
- The draft-release pipeline attaches both supported SBOM formats and the documented ABI manifests with exact-tag/build provenance.
- Checksums/signatures verify against the uploaded bytes and intended identity before successful publication is reported.
- Missing, stale, substituted, tampered, or inconsistent artifact sets fail required-mode validation.
- Contract tests cover positive verification, negative identity/content cases, partial publication, and retry without overwriting immutable assets.
- Source-archive behavior and signing-permission boundaries remain covered by regression checks.
- Downstream verification instructions cover all new assets and clearly identify retained manual/operational GA steps.
Target: 0.90.0 preparation; #687/#750 retain release-specific evidence and final acceptance. No additional runner-provisioning issue is introduced.
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 10h 5m
- Merged PRs (30d)
- 146
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from semantic-reasoning/wirelog
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
semantic-reasoning/wirelog#2229 ·
Maintainers usually reply within 1 day
-
Doc: insert executor and incremental consolidation leave sorted runs, not globally sorted headsOpen
Difficulty 1/5 Under an hour Newbie friendliness 83/100
semantic-reasoning/wirelog#2133 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
semantic-reasoning/wirelog#2042 ·
Maintainers usually reply within 1 day
-
p2-medium
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
semantic-reasoning/wirelog#1914 ·
Maintainers usually reply within 1 day
-
Refused evaluations still abort or corrupt the retried model when no completion cursor is armedOpen
Difficulty 4/5 3-5 days Newbie friendliness 48/100
semantic-reasoning/wirelog#2348 ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
kind/bug priority/medium qa_automation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yugabyte/yugabyte-db#37324 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
meshcore-dev/MeshCore#3781 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
ly05010419/MacNativeGames#1897 ·
Maintainers usually reply within 1 day
-
area: metrics area: tracing contribfest enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
open-telemetry/opentelemetry-ebpf-instrumentation#4188 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day