Hi Werner, hi Martin,
thank you for including me in the discussion. I'm happy to participate
in any upcoming meeting and/or any direct contact in case that helps.
If anyone is attending either FrOSCon (this weekend) or Open Source
Summit Europe (August 25-29), I'll be happy to meet there in person as well.
Regards,
Carl-Daniel
Am 14.08.25 um 10:52 schrieb Werner Zeh:
Hi Carl-Daniel,
thanks for sharing your point of view on this topic.
As Martin already pointed out this was the outcome of a discussion
with FSFE (Alex) and one of the involved persons in the mentioned
harmonization work ("Essential cybersecurity requirements for boot
managers"), furkami. We will have a follow-up in a broader community
somewhere in September and I will add you to the list of participants.
Would be nice if you could make it so that we have a broader view on
all these points often perceived as controversial.
Werner
Hey Carl-Daniel,
Thanks for the feedback. The information we have that you're
responding to has mostly been provided by the FSFE. Werner is working
to set up a second meeting with the OSFF, which is how we were
thinking about coordinating with other projects. I'll ask him to
reach out to you if you'd be available for a meeting.
Is it going to be problematic to create a security focussed group of
companies using coreboot to work together to meet the obligations of
fixing issues? Obviously we don't want each company to have to fix an
issue and have them all submit conflicting patches to the project.
Thats another way we were talking about working together.
As far as dealing with embargoed CVEs, how do you suggest that be
handled? I'm assuming that if we don't honor the embargoes, we won't
be informed about the CVEs ahead of time, whick would also be bad. My
thought about how it would work is similar to how I understand it
works with the Linux kernel now -- a patch is developed and
distributed privately so that when the embargo is lifted and the
issue is announced, a fix is already in place for the various
distributions. I may be completely wrong about that, but it made
sense to me.
Thanks again for your feedback.
Martin
Aug 7, 2025 at 17:37 [email protected]:
Hi,
a few remarks about the CRA part of the meeting notes:
Am 07.08.25 um 18:53 schrieb mina--- via coreboot:
# 2025-08-06 - coreboot Leadership Meetings Minutes
[...]
## coreboot Leadership Meeting - Late GMT
## Attendees
Martin Roth, Mina Asante, Jay Talbott, Carl Turner, Michal Kopec,
Alicja Michalska, Ziang Wang, Karthik R, Julius Werner.
## Minutes
[...]
### [Martin] Discuss the EU-CRA
* Summary of the EU-CRA
* (https://en.wikipedia.org/wiki/Cyber_Resilience_Act)
*(https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14449-Technical-description-of-important-and-criticalproducts-with-digital-elements_en)
* (https://www.linuxfoundation.org/research/cra-readiness?hsLang=en)
```
The European Union's Cyber Resilience Act (EU-CRA) is a
comprehensive regulation aimed at improving
the cybersecurity of "products with digital elements" -meaning both
hardware and software -sold
within the EU. The CRA mandates that these products meet strict
cybersecurity requirements
throughout their lifecycle, such as secure-by-default settings,
incident reporting, vulnerability
management, and regular security updates. Products covered by the
CRA range from everyday consumer
electronics to large-scale enterprise systems, though some
categories like medical devices and cars
are governed separately.
Key Provisions & Timeline
The CRA officially entered into force on December 10, 2024.
Most obligations will become mandatory on September 11, 2026, with
full application commencing on
December 11, 2027.
Impact on Open Source Projects
The initial drafts of the CRA raised substantial concern in the
open source community, as its
requirements could have placed undue liability and compliance
burdens on individual contributors
and small non-commercial projects. However, after extensive
advocacy and negotiations, the final
text provides important clarifications and exemptions:
Non-commercial Open Source Exemption: If you maintain or contribute
to open source software purely
in a non-commercial capacity (i.e., you do not sell or distribute
it commercially), the CRA does
not apply to you. The regulation is designed to target commercial
actors and companies that deploy
open source in products for profit.
Commercial Open Source: If an entity distributes open source
software as part of a commercial
activity—including selling, offering paid support, or bundling in
commercial hardware/software—they
must comply with the CRA as "manufacturers" or "distributors." This
means they bear the primary
responsibility for security obligations.
Open Source Stewards: The final legislation introduces the "open
source steward" concept,
recognizing organizations like the Linux Foundation or Eclipse
Foundation. These entities play a
coordination or support role in fostering security practices in
open source projects but are not
automatically liable unless involved in commercial distribution
```
* Werner and I had a meeting with the FSFE to discuss the EU-CRA.
```
No obligations for the project itself, only the manufacturer (user
of the project) is responsible.
Clear for coreboot as such: It is used to enable/build commercial
products. The only responsible
entity is the manufacturer of the final product.
It is expected very little from the project itself:
* provide a proper documentation of the project
* document the CVE-policy (mention how fast you can react, what the
contact address is, when and where fixes are announced ...)
* be available for market surveillance authorities in cases of
questions
coreboot does not have the obligation to fix vulnerabilities. If a
fix is provided, make sure it is
documented and made available to all users. It is enough to have it
merged on main and document it
properly. Putting in release notes can already be enough, too.
There seems to be an incentive to join forces with other users to
form a single entity for all
CRA-related obligations.
I've seen that claim a few times,but I never was able to trace that
claim to its source. Could you enlighten me who suggested that so I
can educate that party?
Once a number of open source projects "join forces" to form a single
entity, their obligations mandated by the CRA increase significantly
because they will most likely be classified as an open source steward.
However, if an organization already is an open source steward, it
makes sense for them to rope in more projects to spread the load/cost.
The coreboot project (even if we consider the wider ecosystem of
related projects such as payloads etc.) is nowhere near being an
open source steward.
Unfortunately, lots of statements about the CRA published by
self-proclaimed experts in the open source world are either simply
wrong or refer to early drafts of the CRA (without explicitly
stating said reference). Such misleading and embarrassing statements
usually are neither retracted nor annotated with "no longer
applicable".
I strongly recommend reading the CRA in its entirety regardless of
whether you consult third parties about interpretation. The law is
really well-written and easy to read (yes, even if you're not a
lawyer) and even contains explanations (what is the intent, how are
certain terms defined).
For example, one often overlooked gem in the CRA is this:
Chapter II, article 13, item 6:
"Manufacturers shall, upon identifying a vulnerability in
a component, including in an open source-component, which is
integrated in the product with digital elements report the
vulnerability to the person or entity manufacturing or maintaining
the component, and address and remediate the vulnerability in
accordance with the vulnerability handling requirements set out in
Part II of Annex I. Where manufacturers have developed a software or
hardware modification to address the vulnerability in that
component, they shall share the relevant code or documentation with
the person or entity manufacturing or maintaining the component,
where appropriate in a machine-readable format."
This means manufacturers must notify upstream about a security bug,
fix the security bug and contribute their security fixe upstream.
This is huge.
Three bullet points when it comes to reporting obligations:
* report vulnerabilities
* report incidents
* volunteer reporting on other issues
Obligation to report is only for known and exploitable
bugs/vulnerabilities. If a bug /vulnerability is under embargo/not
public yet, this obligation does not apply.
Citation needed for the "embargo" part. And no, recital 70 of the
preamble of the CRA can not be interpreted in that way. Yes, I have
read that text. At most, a manufacturer may ask the coordinating
CSIRT to delay dissemination to other CSIRTs and ENISA, but that
does not delay the obligation to report to the coordinating CSIRT
and any such delay is at the discretion of the CSIRT.
In case of doubt, reach out to market surveillance authorities and
ask.
Indeed. Or ask the European Commission. They even held multiple
(extremely helpful) talks and discussions at FOSDEM and other events.
Voluntary security attestation → What does it mean in the context
of OSS?
That would be CRA chapter II, article 25 "Security attestation of
free and open-source software"
Please note that right now there is an active process of writing
harmonized standards (as referenced by the CRA). One such harmonized
standard in development is "Essential cybersecurity requirements for
boot managers". I hope to see someone from the coreboot project
participate in that effort. The timeline for that standards process
is extremely tight and a participation later this year might already
be pointless. There is arguably some overlap between the vertical
"operating systems" and "boot managers", but current consensus seems
to put x86 system firmware in the "boot managers" camp.
(No, I unfortunately don't have time to attend the meetings of the
boot manager harmonized standard on behalf of coreboot, I'm already
working pretty much full-time on another related harmonized
standard. I can provide a crash course for anybody willing to
participate, though.)
Regards,
Carl-Daniel
_______________________________________________
coreboot mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
coreboot mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
