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 by [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 to [email protected] > _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
