You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tooling.apache.org by "sbp (via GitHub)" <gi...@apache.org> on 2025/10/20 15:36:06 UTC
[I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
sbp opened a new issue, #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250
Following on from #87, our attestation story is far less well developed than our bill of materials story. We need to decide what we're going to attest to in the first round of implementation, what format we're going to use, and (if applicable) what the UI contribution will be. At the very least, even if we have an automatable attestation we want users to be able to be aware that it was produced and able to review it.
We should try to follow the lead of GitHub and PyPI et al. here. Although the attestation ecosystem is less well developed than the SBOM ecosystem, there are already some _de facto_ standardised practices emerging. We have been aware of this since the start of development, but we need to make some decisions for the proof of concept.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-4500597903
Attestations are now out of scope
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3423524560
It looks like SLSA is defining an emerging approach. See https://slsa.dev/spec/v1.2-rc1/attestation-model#recommended-suite
As part of that we may be taking bundles produced in the build and adding additional attestations from the ATR to produce a complete bundle for a Release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "asf-tooling (via GitHub)" <gi...@apache.org>.
asf-tooling commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-4410407217
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@2da7807a`
**Type:** `discussion` • **Classification:** `no_action` • **Confidence:** `medium`
**Application domain(s):** `automated_checks`, `announcement_publishing`
### Summary
Issue #250 requests implementing basic attestations (proof of concept) for ATR releases in a standardized format. The discussion converged on SLSA v1.2 as the target framework (@dave2wave noted SLSA v1.2 'has enough defined that we can design more than a proof'), with GitHub's attestation tooling as a practical reference. While ATR already has internal 'attestable' metadata tracking (file hashes, provenance, check results in atr/attestable.py and atr/models/attestable.py), it does NOT yet produce standardized SLSA/in-toto format attestations consumable by external tools. No concrete implementation spec has been agreed upon beyond the general direction.
### Where this lives in the code today
#### `atr/models/attestable.py` — `AttestableV2` (lines 70-74)
_extension point_
Current internal attestable metadata model - tracks file hashes, paths with classifications, and provenance. This data would serve as input to produce SLSA-format attestations.
```python
class AttestableV2(schema.Strict):
version: Literal[2] = 2
hashes: dict[str, HashEntryV2] = schema.factory(dict)
paths: dict[str, PathEntryV2] = schema.factory(dict)
policy: dict[str, Any] = schema.factory(dict)
```
#### `atr/models/attestable.py` — `ProvenanceV2` (lines 59-61)
_extension point_
Internal provenance tracking with a generator enum. This would need to be mapped to SLSA provenance predicates in a standardized attestation format.
```python
class ProvenanceV2(schema.Strict):
generator: GeneratorV2
metadata: dict[str, Any] = schema.factory(dict)
```
#### `atr/attestable.py` — `github_tp_payload_read` (lines 206-227)
_extension point_
GitHub Trusted Publisher OIDC payload reading - this already captures provenance from GitHub Actions which would feed into SLSA provenance attestations.
```python
async def github_tp_payload_read(
project_key: safe.ProjectKey, version_key: safe.VersionKey, revision_number: safe.RevisionNumber
) -> github.TrustedPublisherPayload | None:
payload_path = github_tp_payload_path(project_key, version_key, revision_number)
if not await aiofiles.os.path.isfile(payload_path):
return None
try:
async with aiofiles.open(payload_path, encoding="utf-8") as f:
data = json.loads(await f.read())
if not isinstance(data, dict):
log.warning(f"TP payload was not a JSON object in {payload_path}")
return None
# Remove exp and nbf if they're stored - as of 2026-03-18 they're validated and then removed before storage
# but we might have older data
if "exp" in data:
del data["exp"]
if "nbf" in data:
del data["nbf"]
return github.TrustedPublisherPayload.model_validate(data)
except (OSError, json.JSONDecodeError) as e:
log.warning(f"Failed to read TP payload from {payload_path}: {e}")
return None
```
#### `atr/models/attestable.py` — `AttestableChecksV2` (lines 94-96)
_extension point_
Records check results per file - these check outcomes would be attestable claims in a standardized format.
```python
class AttestableChecksV2(schema.Strict):
version: Literal[2] = 2
checks: dict[str, dict[str, str]] = schema.factory(dict)
```
#### `atr/storage/writers/announce.py` — `CommitteeMember.release` (lines 103-115)
_extension point_
The release publication workflow - a natural point where finalized attestations could be generated and published alongside the release artifacts.
```python
async def release( # noqa: C901
self,
project_key: safe.ProjectKey,
version_key: safe.VersionKey,
preview_revision_number: safe.RevisionNumber,
email_to: str,
body: str,
download_path_suffix: safe.RelPath | None,
fullname: str,
subject_template_hash: str | None = None,
email_cc: list[str] | None = None,
email_bcc: list[str] | None = None,
) -> None:
```
#### `atr/tasks/checks/signature.py` — `check` (lines 38-50)
_currently does this_
Existing signature verification check - its results (valid signature, signer identity) would be claims in a SLSA attestation.
```python
async def check(args: checks.FunctionArguments) -> results.Results | None:
"""Check a signature file."""
recorder = await args.recorder(CHECK_VERSION)
if not (primary_abs_path := await recorder.abs_path()):
return None
if not (primary_rel_path := args.primary_rel_path):
await recorder.exception("Primary relative path is required", {"primary_rel_path": primary_rel_path})
return None
artifact_rel_path = str(primary_rel_path).removesuffix(".asc")
if not (artifact_abs_path := await recorder.abs_path(artifact_rel_path)):
return None
```
### Where new code would go
- `atr/slsa.py` — new file
New module to generate SLSA v1.2 attestations (in-toto format statements) from ATR's internal attestable data, check results, and provenance information.
- `atr/models/slsa.py` — new file
Pydantic models for SLSA v1.2 attestation predicates (provenance, verification summary) following the in-toto statement specification.
- `atr/tasks/attestation.py` — new file
Task to generate attestations at appropriate lifecycle points (post-vote, pre-release) using the internal metadata and check results.
### Proposed approach
The implementation would involve: (1) Creating Pydantic models for SLSA v1.2 in-toto attestation statements (subjects with digests, predicates for provenance), following the spec at slsa.dev/spec/v1.2/attestation-model. (2) Building a module that transforms ATR's internal attestable data (AttestableV2 paths/hashes, check results, GitHub TP payloads) into SLSA-format attestations. (3) Integrating attestation generation into the release lifecycle — likely at the point where a release transitions to preview or is published. (4) Exposing generated attestations in the UI so users can review them, and making them downloadable alongside release artifacts.
However, since the discussion is still collecting references and no concrete implementation decisions have been documented (e.g., which specific SLSA predicate types to emit first, whether to use Sigstore bundles or standalone statements, how to sign the attestations), this issue remains in the design phase. The team should decide: what predicates to emit (provenance? verification summary?), what signing mechanism (ASF project keys? Sigstore?), and what the minimal viable attestation looks like before coding begins.
### Open questions
- Which SLSA predicate types should be implemented first - provenance (build origin), verification summary (checks passed), or both?
- Should attestations be signed with ASF project OpenPGP keys, Sigstore/Fulcio certificates, or both?
- Should attestations follow the in-toto bundle format (as used by GitHub/PyPI) or be standalone JSON statements?
- At what lifecycle point should attestations be generated - at each revision commit, at vote start, at release publication, or all of the above?
- How should the OIDC issuer policy enforcement (Piotr's request documented by @sbp) interact with the basic attestation PoC?
- Is there an existing Python library for producing SLSA/in-toto attestations that should be used (e.g., in-toto-python, sigstore-python)?
_The agent reviewed this issue and is not proposing patches in this run. Review the existing-code citations and open questions above before deciding next steps._
### Files examined
- `atr/models/attestable.py`
- `atr/attestable.py`
- `atr/tasks/checks/__init__.py`
- `atr/hashes.py`
- `atr/tasks/checks/signature.py`
- `atr/storage/writers/announce.py`
- `atr/tasks/checks/hashing.py`
- `atr/detection.py`
---
*Draft from a triage agent. A human reviewer should validate before merging any change. The agent did not run tests or verify diffs apply.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3534651963
GitHub API to retrieve a list of attestations about a repository. https://github.com/apache/tooling-docs/issues/60
Action that creates attestations - https://github.com/actions/toolkit/tree/main/packages/attest
These give some understanding of what is in these attestations and whether Piotr's statement is feasible on the ATR side.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3522840941
[Piotr P. Karwasz asks](https://the-asf.slack.com/archives/C049WADAAQG/p1762950994138959): "Will there be some kind of policy, we can enable, to ensure that all the releases have an attestation from a given OpenID Connect issuer?"
This is the closest issue, so I'm documenting it here, but it's probably beyond the scope of basic attestations. There are other comments in that thread too which may be relevant here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3582915724
https://github.com/actions/toolkit/tree/main/packages/attest
https://docs.github.com/en/rest/users/attestations?utm_source=chatgpt.com&apiVersion=2022-11-28
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3577457780
[SLSA framework GitHub org](https://github.com/slsa-framework)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3573221081
[SLSA v.12](https://slsa.dev/spec/v1.2/attestation-mode) l was released today. It looks there is enough defined that we can design more than a proof.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #250:
URL: https://github.com/apache/tooling-trusted-releases/issues/250#issuecomment-3583087027
https://github.com/orcwg/cra-attestations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Implement basic attestations as a proof of concept (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave closed issue #250: Implement basic attestations as a proof of concept
URL: https://github.com/apache/tooling-trusted-releases/issues/250
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org