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
Below are some edited AI notes from today's meeting:
Present:
Eric Finco (ST)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Kamlesh Gurudasani (TI)
Frank (Nordic)
David Brown (Linaro)
Joanna Farley (Arm)
Dominik Ermel (Nordic Semi)
Quick recap
The meeting focused on several key topics related to Trusted Firmware development and project policies. The group discussed changing the "co-developed by" tag format in the AI-assisted contributions policy<https://www.trustedfirmware.org/aipolicy/> to align with the new Linux project guidelines<https://github.com/torvalds/linux/blob/master/Documentation/process/coding-…>, with Kamlesh noting that some TF-A patches<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/39036> had already used the "co-developed-by" tag.
The team reviewed a Zephyr interpretation<https://docs.zephyrproject.org/latest/security/standards/cyber-resilience-a…> of the CRA (Cyber Resiliency Act) requirements and their implications for vulnerability handling and SBOM generation, though David emphasized the importance of avoiding legal advice in the documentation unless it's been reviewed by a lawyer.
Antonio presented options for creating a separate PSA crypto driver repository on GitHub, with Frank explaining that the main driver was familiarity with GitHub for vendors, though licensing concerns were raised.
The conversation ended with Dan advertising a new Confidential Compute Working Group<https://corecollective.dev/working-groups/> at CoreCollective that would kick off the following week, initially focusing on CCA reference SW roadmap and CCA attestation enablement.
Next steps
*
Dan: Send an offline message to the group proposing the change to the "co-developed by" tag in the AI policy and proceed with the change if there are no objections.
*
Dan: Run the proposed tag change by the maintainers and ensure everyone who is using the tag is notified if the change proceeds.
*
Antonio (and relevant team members): Discuss further with Gilles and the PSA-Crypto team regarding the creation and use of a new GitHub repo for PSA crypto driver prototyping, including considerations around licensing, building, and testing.
Summary
AI-assisted Contribution Policy Discussion
The team discussed changing the "co-developed by" tag in the AI-assisted contributions policy<https://www.trustedfirmware.org/aipolicy/> to align with the new Linux project guidelines<https://github.com/torvalds/linux/blob/master/Documentation/process/coding-…>, which uses an assisted-by tag with a specific format. The Linux policy is otherwise well aligned. Attributions are optional. Dan proposed sending an offline notification about the proposed change since no objections were raised during the meeting. Kamlesh pointed out that some TF-A patches<http://some%20TF-A%20patches> had already used the "co-developed by" tag. The team agreed this is just for audit purposes so there should be no need to change existing code.
CRA Compliance Documentation Discussion
The team discussed a Zephyr analysis<http://Zephyr%20interpretation> <http://Zephyr%20interpretation> of the CRA and its implications for open source stewardship, with David explaining that that document had been reviewed by lawyers since it contains legal advice about CRA interpretations. Eric proposed using future funding to prepare materials for due diligence, but the group agreed to focus on factual statements about their current practices rather than making interpretive claims about CRA compliance. David raised concerns about the target audience for additional compliance features, noting that many Trusted Firmware members are SOC manufacturers rather than device vendors who would face direct CRA compliance requirements. The discussion concluded with questions about due diligence requirements and vulnerability reporting timelines, which David noted might be more aggressive than current practices.
PSA Crypto Repository Planning
The team discussed creating a new GitHub repository for prototyping PSA crypto drivers, with Frank explaining that the main reason was to align with most vendors' existing GitHub workflows. Antonio raised concerns about licensing issues and building/testing processes for the new repository. The group also learned about an existing PSA crypto API repository<https://review.trustedfirmware.org/plugins/gitiles/shared/tf-psa-crypto-dri…> on Gerrit, but noted it doesn't address licensing requirements for code hosting. Dan noted the existing PSA Crypto API GitHub<https://github.com/ARM-software/psa-crypto-api> doesn't look suitable for code sharing as there is no license information.
AOB
The conversation ended with an announcement about a new Confidential Compute Working Group<https://corecollective.dev/working-groups/> kickoff planned for the following week.
