Re: 2025-08-06 - coreboot Leadership Meetings Minutes

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]