This was extracted (@ 2025-06-25 23:10) from a list of minutes
which have been approved by the Board.
Please Note
The Board typically approves the minutes of the previous meeting at the
beginning of every Board meeting; therefore, the list below does not
normally contain details from the minutes of the most recent Board meeting.
ASF Members may have access to a
private draft
WARNING: these pages may omit some original contents of the minutes.
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/
A report was expected, but not received
A report was expected, but not received