asf-tooling commented on issue #614:
URL:
https://github.com/apache/tooling-trusted-releases/issues/614#issuecomment-4410145148
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@2da7807a`
**Type:** `discussion` • **Classification:** `no_action` •
**Confidence:** `high`
**Application domain(s):** `sbom_analysis`, `shared_infrastructure`
### Summary
This is a tracking/discussion issue for integrating ATR with ECMA TC54
standards. Three of four items are already checked off: ECMA-428 CLE is
implemented in `atr/cle.py`, ECMA-424 CycloneDX is used throughout `atr/sbom/`,
and ECMA-427 Package-URL is used in both modules. The remaining item
(TEA/Transparency Exchange API) was explicitly deferred by @dave2wave who
stated 'I do not want to implement a TEA server' and the team decided to 'take
some time to evaluate.' @taleodor noted that if PURLs are figured out properly,
adding TEA later would be easier.
### Where this lives in the code today
#### `atr/cle.py` — `_identifier` (lines 145-152)
_currently does this_
Shows ECMA-428 CLE implementation already uses Package-URL (ECMA-427) as the
identifier, referencing the PURL spec issue discussed in the thread.
```python
def _identifier(project: sql.Project) -> str:
"""Render the project as a Package-URL.
`pkg:apache/<project_key>` is the simplest form. Per-distribution PURLs
(`pkg:maven/...`, `pkg:pypi/...`) belong on the artifact catalog (#911),
not on the lifecycle doc. This may change with outcome of
https://github.com/package-url/purl-spec/issues/516
"""
return f"pkg:apache/{project.key}"
```
#### `atr/cle.py` — `project_document` (lines 62-75)
_currently does this_
Public API for generating ECMA-428 CLE documents for a project,
demonstrating that this standard integration is complete.
```python
def project_document(
project: sql.Project,
events: Iterable[sql.LifecycleEvent],
releases: Iterable[sql.Release],
*,
now: datetime.datetime,
) -> dict[str, Any]:
"""Generate a CLE document covering every event for a project.
This is the canonical form per ECMA-428: one document per component.
`releases` are needed to resolve version strings and cycle release sets
at render time.
"""
return _document(project, list(events), list(releases), now=now)
```
#### `atr/sbom/conformance.py` — `ntia_2021_issues` (lines 258-265)
_currently does this_
NTIA conformance checking explicitly references ECMA-424 (CycloneDX 1st
edition), showing the standard is already integrated into SBOM analysis.
```python
def ntia_2021_issues(
bundle: Bundle,
) -> tuple[list[models.conformance.Missing],
list[models.conformance.Missing]]:
# 1. Supplier
# ECMA-424 1st edition says that this is the supplier of the primary
component
# Despite it being bom.metadata.supplier and not
bom.metadata.component.supplier
# bom.metadata.supplier,
# bom.components[].supplier
```
#### `atr/sbom/osv.py` — `_component_purl_with_version` (lines 173-188)
_currently does this_
Package-URL (ECMA-427) is already used extensively via the `packageurl`
Python library for vulnerability scanning.
```python
def _component_purl_with_version(component: Component) -> str | None:
# If we don't know the purl, we can't help
if component.purl is None:
return None
# If the component purl includes version information, return it
if component.purl.version is not None:
return str(component.purl)
# If not, and we don't have a component version, we still can't add
anything
if component.version is None:
return None
version = component.version.strip()
if (not version) or version == "UNKNOWN":
return None
# Make a new purl so we don't affect the component definition
purl = PackageURL.from_string(str(component.purl))
return str(PackageURL(purl.type, purl.namespace, purl.name, version,
purl.qualifiers, purl.subpath))
```
#### `atr/models/sql.py` — `LifecycleEventType` (lines 262-268)
_currently does this_
Database enum supporting ECMA-428 CLE lifecycle events, demonstrating that
the data model layer already supports CLE.
```python
class LifecycleEventType(enum.StrEnum):
RELEASE = "release"
ARCHIVE = "archive"
WITHDRAW = "withdraw"
EOD = "eod"
EOS = "eos"
EOL = "eol"
```
### Proposed approach
This is a discussion/tracking issue with no immediate code action needed.
Three of the four ECMA standards are already integrated: ECMA-428 CLE is
implemented in `atr/cle.py`, ECMA-424 CycloneDX is the foundation of the entire
`atr/sbom/` subsystem, and ECMA-427 Package-URL is used throughout via the
`packageurl` Python library. The remaining item (TEA) was explicitly deferred
by the team, with @dave2wave stating they don't want to implement a full TEA
server and will evaluate later. @taleodor pointed to existing TEA
implementations (Oolong, ReARM, sbomify) that could potentially be adopted in
the future. The team also noted ongoing work with the PURL group (via
@mjherzog) on a proper Apache PURL type, and @ppkarwasz suggested ATR could
help uniformize download directory layouts to make PURL resolution feasible.
### Open questions
- What is the status of the PURL type discussion (package-url/purl-spec#516
SCID proposal) that would allow PURLs for C/C++ projects like Apache Httpd?
- Has the team decided whether to use an 'asf' PURL type vs the generic SCID
approach for source releases?
- Is there a separate issue tracking the catalog/rewriter endpoint
@dave2wave mentioned for standard URL patterns?
- When will the team revisit TEA integration - is there a timeline or
blocking condition?
_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/cle.py`
- `atr/models/sql.py`
- `atr/sbom/cli.py`
- `atr/sbom/conformance.py`
- `atr/sbom/licenses.py`
- `atr/sbom/osv.py`
- `atr/sbom/utilities.py`
- `atr/sbom/__init__.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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
