| This can of course also lead to interesting situations where the maintainers don’t accept a fix provided, but either fix in another way or don’t acknowledge the problem.
In that situation, how will integrators react? I think there are good answers and really disturbing answers based on my experience.
The text in the CRA just puts the obligation on the integrator, not on the project to accept the fixes.
Cheers, /O On 14 Jun 2024, at 11:47, Tobie Langel via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Yes, the GPL-like requirements for upstreaming vulnerability fixes are a fascinating feature of the CRA.
I'd imagine they'd be part of the discussion on vulnerability handling (in the second list). WDYT?
Hi!
While getting up to date with my knowledge about the CRA I was surprised to learn integrators will need to fix security issues and/or to provide fixes back to the OSS projects. I think this will lead to a set of new requirements for OSS projects to publish ways of contact and probably standard rates for support work.
Where would you put such thoughts?
Best
Tobias (iJUG e.V.)
Hi all,
I'm preparing a form to gather your input on CRA-related discussion topics and activities you'd like to get involved with.
Here's a list of general topics taken from Gaël's presentation yesterday:
- CRA reading group
- Building support documentation (glossary, collecting references, etc.)
- How to ensure effective participation in the EU standardization process
- How to provide input to the EU Commission in general (and about product categorisation in particular)
- CRA impact on Open Source Stewards / foundations
- CRA impact on open source consumers (SMEs / enterprise / OSPOs)
- CRA impact on single-vendor open source
And here's a list of the more technical topics he shared:
- Standards for identifiers (CPEs), version numbers, end-of-live status & dates, referencing (transitive) dependencies, etc
- Standards for releases, recall, EOL
- Secure by design
- Open source supply chain security
- Vulnerability handling
- Software lifecycle; including post EOL vulnerabilities
Any pressing topics I'm missing?
Thanks for your input,
--tobie
---
Tobie Langel
Tech Lead ORC WG, Eclipse Foundation
Principal, UnlockOpen
-- Frech IT GmbH / Am Brünnele 7 / 71642 Ludwigsburg phone : +49-(0)7141-9113037 / HR B 744851 / AG Stuttgart
Geschäftsführer: Tobias Frech mobile: +49-(0)172-7112352 / email: tobias@xxxxxxxxxx
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
|
