Hi all
Below are the belated minutes from the last TSC meeting.
One update from this: Linaro is now a CNA:
https://www.cve.org/PartnerInformation/ListofPartners/partner/Linaro
Shebu: I don't have the slides you presented. Could you reply-all with them here when you're back in the office.
Regards
Dan.
Present
(I think this is incomplete - Zoom doesn't seem to have recorded everyone who joined the call).
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Janos Follath (Arm)
David Brown (Linaro)
Kamlesh Gurudasani (TI)
Frank Audun (Nordic)
Julius Werner (Google)
Key Outcomes
* PSA Crypto/mbed TLS maintenance is at risk; current maintainers plan to stop development/maintenance by April 27, and the project is actively seeking new contributors or organizations to take over.
* PSA Crypto API support is progressing: mbed TLS 3.6 LTS supports PSA Crypto 1.1, and mbed TLS 4.1 supports 1.2 (with some gaps); full 1.5 support is in progress.
*
PQC support is moving forward: ML-DSA is implemented via a fork of the ML-DSA native project from the PQC Alliance, with PSA Crypto API support expected by the end of the year.
*
TF security incident handling is being streamlined to reduce overhead and speed up fixes, including a proposal to decouple CVE creation from vulnerability fixing and move toward a more kernel-like model.
* Zephyr is proposing to end embargoes once a fix is merged into Git, as AI tools make embargoes less effective.
Decisions Made
* PSA Crypto 1.2 will not be backported to mbed TLS 1.x; a separate version was released for that branch.
* Security fixes in TF PSA Crypto 1.2 will be backported to the 1.x LTS branch.
*
TF PSA Crypto ML-DSA implementation will leverage the ML-DSA native project from the PQC Alliance rather than a from-scratch implementation.
*
TF PSA Crypto will only support ML-DSA-87 initially
*
TF PSA Crypto driver repository has moved to the Mbed TLS GitHub organization and is open for vendors to push their PSA Crypto drivers.
Progress & Status
* mbed TLS maintenance transition: Board members and downstream consumers are checking for funding or personnel within their organizations; some positive queries have been received, but no solid agreements yet.
*
ML-DSA: The team is actively working on ML-DSA support via the PSA Crypto API this quarter.
* Security issues: The bug bounty program has been paused, and the volume of new incoming issues is decreasing, though a considerable backlog remains.
* mbed TLS 3.6 LTS will reach end-of-life in March 2027; users are encouraged to migrate to 4.x and PSA Crypto APIs.
*
Chinese crypto algorithms (SM2, SM3, SM4) are being investigated for potential upstreaming via PSA API or driver interfaces.
* Linaro is expected to become a CNA, which may provide more reliable CVE creation for TF projects.
Risks & Blockers
* Maintenance risk: If no new maintainers step up by April 27, mbed TLS and X.509 libraries may stop receiving security fixes and regular updates.
* PR review capacity: PR review remains a challenge for the PSA Crypto project; more reviewers are needed.
* Security process overhead: High volume of reports, complex triage, and manual CVE/advisory management are slowing down fixes.
* CRA implications: The Cyber Resilience Act (CRA) may impose reporting requirements on open-source stewards, including a 24-hour deadline for actively exploited vulnerabilities, which is seen as unrealistic for volunteer-led projects.
* AI-generated reports: AI tools are increasing the volume of reports, some of which are low-quality or duplicates, adding to the triage burden.
Pending Confirmation
* New maintainers for mbed TLS and X.509 libraries need to be identified and committed before the April 27 deadline.
* ML-KEM is on the roadmap but work has not yet started; it will likely follow the completion of ML-DSA.
* CRA requirements for open-source stewards remain unclear and are expected to be resolved by December of next year.
*
Proposed security process changes need further review from maintainers.
Action Items
* Shebu: Collate responses from organizations regarding mbed TLS maintenance and have Bharath present them at the next board meeting.
*
Dan: Create a PR for the proposed security incident handling process changes and send it for formal review by the TSC and project security teams.
*
Mbed TLS users: Consider moving to mbed TLS 4.x and PSA Crypto 1.1 before the 3.6 LTS end-of-life in March 2027.
* HW Vendors: Encouraged to push their PSA Crypto drivers to the new TF PSA Crypto driver repository.
Hi all
I have the following topics so far for the meeting tomorrow:
*
PSA Crypto API version roadmap for TF-PSA-Crypto / Mbed TLS (including LTS).
*
Proposal for changes to the TF security incident handling process.
Regards
Dan
Hi all
Sorry for the late notice but tomorrow's TSC meeting is cancelled as we don't have any prepared topics for this. Let us know if you have anything urgent to discuss and we will rearrange.
Regards
Dan.
I would like clarification on how the Trusted Firmware bug bounty program handles researcher priority when submissions remain with Intigriti for an extended triage period.
Intigriti triage can currently take approximately one to two months. During that period, it is possible for Arm or the Trusted Firmware project to independently discover, investigate, or fix the same vulnerability before Intigriti completes triage and forwards the submission.
In that situation, what point in time is used to determine whether a report is considered “already known” or a duplicate?
Specifically, is priority determined using the researcher’s original submission timestamp, or the later date on which Intigriti completes triage and the report reaches Arm?
If a researcher submits a vulnerability first, but Arm independently discovers or fixes the same issue while that submission is still awaiting Intigriti triage, does the researcher retain priority and bounty eligibility?
Conversely, if Arm considers the issue to have already been known before the researcher submitted it, what timestamp or internal record is used to establish that the issue predates the submission?
Finally, does Arm PSIRT or the Trusted Firmware security team receive any information about submissions while they are still in Intigriti’s Triage state, or are reports only passed to Arm after Intigriti completes triage.
Best regards,
Guled
Dears,
Writing to inform you that we're going to cancel the upcoming TSC meeting scheduled for this Thursday as several people are on summer break. We will reinstate the series starting from the September meeting.
@Shaun Longhorn<mailto:shaun.longhorn@linaro.org> can you please cancel the August meeting?
Thanks,
Antonio
Sent from Outlook for Mac
Hi all
Sorry for the late notice, but today's TSC meeting is cancelled. We don't have a strong agenda and we expect low attendance anyway.
Regards
Dan.
Hi all
The agenda for this week's TSC meeting so far is:
*
Firmware-A roadmap (TF-A, TF-RMM, Hafnium)
*
TF-M roadmap
*
TF-PSA-Crypto roadmap
Let me know if you have any other topics.
Regards
Dan.
Hi all
I've sent this to what I hope is a representative subset of TrustedFirmware.org project maintainers. Feel free to forward to others you think should be included.
I'm writing to gather maintainer feedback on a proposal for TrustedFirmware.org to have a policy on the use of AI-assistants in code contributions. Several other open-source organizations already have their own policies. Attached is the current draft of that policy, which is based on the Linux Foundation and Apache Software Foundation guidance. This has been discussed at the TF.org board and more recently, the TSC (see minutes here<https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o…>). Eric Finco @ ST had 2 pieces of feedback to this, the 2nd of which prompted me to seek this wider input. To summarize that feedback:
1. Eric would like all contributions that use AI assistants to explicitly attribute the tool(s) used in the contribution for transparency reasons. The counter feedback is that this might be onerous to generate (especially if a tool has a complex backend) and there is no clear use for that information.
2. Eric would like the policy to apply to all TrustedFirmware.org projects, rather allowing projects to develop their own project-specific guidance (as per the current draft).
Some of this might require more interaction discussion. My plan was to invite you all to a future TSC meeting (perhaps in September) to discuss further. I'm happy to take feedback on the policy, Eric's feedback or the process to handle this. Feel free to reply to this email (to all or just to me), or just wait for that TSC meeting.
Best regards
Dan.
Hi all
Let me know if you have any topics for Thursday's TSC meeting. So far I have:
*
Integration of PSA-Crypto and Hw Accelerator driver support in TF-A (proposed by ST).
*
Project health discussion, given increasing maintainer bandwidth constraints.
Regards
Dan.
