What the board has decided about this committee or office, and the reports it filed, most recent first. Generated from the published minutes.
These categorised views are best effort. They are read from the published minutes by a program, and what it can attribute to a committee depends on how each resolution happens to be worded — so a page may be incomplete, and nothing here overrides the minutes themselves. The raw minutes are the source of truth.
Please note. The board approves the minutes of a meeting at the meeting after it, and they are published then - so the most recent meeting is not usually here. ASF Members can read the draft in the board's own repository until it is.
[raw] the published minutes, which are the record. [main index]
| Date | Action | Decided by |
|---|---|---|
| 2024-12-18 | Appointed Piotr P. Karwasz | the board, by resolution |
The CycloneDX working group has submitted the Threat Model BOM proposal to ECMA TC-54: https://github.com/Ecma-TC54/meetings/issues/9 This BOM format only **partially** covers the information we provide in our descriptive threat model pages. LLM-generated TM-BOMs are available here: https://s.apache.org/tm-bom Most notably, the format does not allow us, out of the box, to define which threats are in-scope versus which are the operator's responsibility, but we can work around this using custom ASF properties.
Nothing to report this month.
Work in all ECMA TC-54 committees is continuing. After months of discussion, the question of whether the ASF should define its own Package URL type (`asf`) or adopt the emerging `sid` type appears to be approaching resolution. At the most recent TG-2 meeting, consensus formed around identifiers of the form: ``` pkg:sid/apache.org/... ``` See https://github.com/package-url/purl-spec/issues/834 for context. The `sid` type has two subtypes. The commercial software subtype has stalled pending industry feedback, but the domain-based subtype is mature enough to be ratified in the near term if the ASF needs it.
Work at ECMA TC-54 is proceeding as usual, without any major announcements.
Within the various ECMA TC54 task groups:
* TG-1 (Transparency Exchange API – TEA)
TG-1 will not submit a first version of the Transparency Exchange API to
ECMA in June. Instead, version 1.0 will first be released as a “community
version”, with standardization expected in September. Since TEA has grown
significantly in size since its inception, there is an ongoing discussion
within ASF Tooling regarding which parts of the specification should be
supported by Apache Trusted Releases (ATR):
https://github.com/apache/tooling-trusted-releases/issues/614
* TG-2 (Package URL – PURL and VERS)
TG-2 is currently focused on the proposed
“SCID” PURL type: https://github.com/package-url/purl-spec/issues/516
This proposal introduces a Package URL type for non-packaged software. It
could be relevant to the ASF for identifying not only C/C++ projects and
other languages without traditional packaging systems but also binary
executable distributions produced by many projects. During discussions it
was also noted that publishing PURLs for ASF artifacts might warrant
consultation with ASF Legal, since ASF binaries are “convenience binaries”
rather than official foundation releases. Using identifiers containing
“apache.org” or “The Apache Software Foundation” may therefore have legal
implications.
* TG-4 (OSS Sustainability)
TG-4 continues work on a model to express project sustainability needs in a
machine-readable form. Recent discussions have focused on representing both
traditional OSS contribution needs (e.g., “triagers needed”) and potential
funding opportunities (e.g., “additional triaging bandwidth available if
funded”). It may be worth evaluating whether committers could express these
needs within ASF repositories, or whether doing so would conflict with ASF
bylaws.
Activity within ECMA TC54 task groups was limited in January, largely due to preparations for FOSDEM. In parallel, ASF Tooling has initiated a discussion on integrating the newly ratified ECMA standards into Apache Trusted Releases: https://github.com/apache/tooling-trusted-releases/issues/614
There were no noteworthy developments this month.
At the ECMA General Assembly on December 10th, the following TC54 standards were ratified: 1. CycloneDX Bill of Materials Specification (2nd edition; ECMA-424) https://ecma-international.org/publications-and-standards/standards/ecma-424/ This standard has also been submitted to ISO/IEC JTC1 for fast-track standardization. CycloneDX, together with SPDX (ISO 5962), is directly relevant to Apache Trusted Releases. 2. Package URL (PURL) Specification (ECMA-427) https://ecma-international.org/publications-and-standards/standards/ecma-427/ This standard has likewise been submitted to ISO/IEC JTC1 for fast-track standardization. 3. Common Lifecycle Enumeration (ECMA-428) https://ecma-international.org/publications-and-standards/standards/ecma-428/ CLE forms the conceptual model for the Apache Trusted Release catalog: https://github.com/apache/tooling-trusted-releases/issues/183 At the TC54 meeting on December 11th, the committee approved a change in convenors for TC54-TG4 (OSS Sustainability). Steve Springett (ServiceNow) stepped down and the role will now be jointly held by Chris de Almeida (IBM) and myself on behalf of the ASF.
No new activity this month, as the Common Lifecycle Enumeration, Package URL, and CycloneDX 1.7 proposals await Executive Committee and December General Assembly decisions.
At its September 18th meeting, TC54 submitted three draft specifications to the ECMA Executive Committee for ratification at the December General Assembly: * Second Edition of ECMA-424 (CycloneDX v1.7): Enhances the existing BOM standard, with improvements focused on the CBOM format. https://ecma-tc54.github.io/ECMA-424/ * Package-URL Specification (https://ecma-tc54.github.io/ECMA-xxx-PURL/): Provides a consistent way to identify packaged components, and is expected to be adopted by the CVE Program for vulnerability reporting. For non-packaged software (e.g., ASF C projects), a generic PURL type has been proposed (https://github.com/package-url/purl-spec/issues/516). Notably, new PURL types can be registered even after standard ratification. * Common Lifecycle Enumeration (CLE) Specification (https://ecma-tc54.github.io/ECMA-xxx-CLE/): Defines machine-readable lifecycle events for software releases. Of particular interest to the ASF are the `released`, `endOfDevelopment`, and `endOfSupport` events, which could be integrated into the Apache Trusted Releases platform.
Two TC54 task groups have prepared draft standards that will be submitted for discussion at the September TC54 meeting: * TG2: Package URL (https://github.com/package-url/purl-spec) * TG3: Common Lifecycle Enumeration (https://github.com/Ecma-TC54/tg3/blob/main/SPECIFICATION.md) If endorsed by TC54, these drafts will be forwarded to the ECMA Executive Committee and, if approved, ratified by the ECMA General Assembly in December.
There were no significant developments in ECMA TC54 this month.
* The ECMA General Assembly has officially confirmed the ASF as a full member[1]. We now have full voting rights within the organization. * The CycloneDX OSS Sustainability Workgroup is transitioning into a new task group (TG4), provisionally named "Dugnar"[2]. * The estimated delivery timeline for TG1 Transparency Exchange API has been revised, with completion now targeted for June 2026. * Unfortunately, my recent call for volunteers[3] to represent the ASF in TG3 (Common Lifecycle Enumeration) and the upcoming TG4 (Dugnar) did not receive any responses. At present, we have no ASF representatives participating in these task groups. [1] https://ecma-international.org/news/ecma-international-welcomes-new-members-9/ [2] https://docs.google.com/document/d/1Dlfq1vp2xXDN1oeUPVGffMEtagUUH1CQ2jWOTg4H9UE/edit?tab=t.0#heading=h.si64e7edhupe [3] https://lists.apache.org/thread/jg342k6h0gvxykldv8cwjpd6mfjonz78
- The expected deadline for the submission of the Transparency Exchange API standard was moved from December 2025 to June 2026. - No other significant news.
The ECMA TC 54 (Software Transparency) committee is currently working on three
standards, due to be published at the end of 2025, and updates to the
CycloneDX standard:
1. Transparency Exchange API[1]: The standard will specify a common HTTP API
to query security-related documents (SBOMs, vulnerability disclosures,
attestations, end-of-life dates, etc.) from a software vendor.
A beta1 of TEA was released on May 9th. The standard is still not stable
with frequent changes to the specification. When it will become stable,
around September, it would interesting to integrate it into ATR.
[1] https://github.com/CycloneDX/transparency-exchange-api
2. Package URL: The standard aims at assigning an identifier to each software
package and replace the CPE standard that is used in vulnerability
disclosures.
The standard is mature and will not introduce any breaking changes. The CVE
Project is considering PURL as a replacement for CPE and
`collectionURL/packageName` identifiers currently used to designate
affected packages.
PURLs are used to designate the "convenience binaries" that the ASF
publishes to ecosystem-specific repositories, but there is also a
proposal[2] to create a PURL type for the source and binary archives
publishes on `downloads.apache.org`.
[2] https://github.com/package-url/purl-spec/issues/305
3. Common Lifecycle Enumeration: The purpose of the standard is to provide
end-of-life and other lifecycle information for software releases in a
uniform way. Currently there is only a draft of the standard available at
[3].
The types of events considered by CLE are mostly targeted at commercial
companies. Some input from the ASF might be required to include the
lifecycle events of OSS projects. Since I am unable to attend CLE meetings,
I will ask for volunteers among ASF members.
Since lifecycle information (EOL dates) are very hard to find, even in
human-readable form, it might be useful to ask PMCs to include a webpage
that lists the support status of all the published software releases.
[3] https://github.com/Ecma-TC54/tg3/pull/3
4. Related to CLE, an OSS Sustainability WG[4] was created inside CycloneDX.
Its purpose is to mark projects that lack active maintenance, like projects
in the Attic or the dormant subprojects of TLPs.
I am not actively participating in the meetings of this group.
[4]: https://cyclonedx.org/participate/working-groups/