This is the request which will allow the three european standardization organizations (CEN, CENELEC, ETSI) to draft the required 41 standards for the Cyber Resilience Act (CRA). See page 17 and following for the list.
To participate in the standardization you have to be part of a "national body" and they will "send" you to participate in EU standardization.
I know no one from my FOSS circles who has any experience there, as most relevant standards for us are written outside of these organizations (W3C, IETF etc.)
If you are interested in this please send me an email, we're trying to put together a guide on how to engage in "official" standardization efforts as Open Source people.
The effort from this blog post is (amongst other things) trying to establish a whole new way of engaging with the EU. We need both approaches.
I'd like to give my comments on the new standards, but I'm never going to be chosen to be part of an elite squad of standards-writers. Is there any chance of the standards developing more in the open, with a community in addition to the committee?
It is not so much an elite squad as more a bunch of people willing to spend the entrance fee and to commit their time. The exact requirements depend on the country you're in though.
So if that is your only concern but you are willing to spend time feel free to reach out.
The effort from the blog post is partially about a long term plan to get the EU to change this. But in the short term it'll be hard to change the rules in time for the CRA standards.
My only fear is that every vendor will now have to implement secure boot and other mechanisms in order to make sure that only signed software runs on their devices, while providing no way for the customer to take ownership of the device back, so that they can run their own software.
I really hope that we eventually get a mandate so that every device, that requires an internet connection for any and all features, will also have to allow the customer to overwrite and use their own software in case they have to make any software/security repairs themselves.
Strict launch integrity (unlike "secure boot") depends on a customer-defined root of trust. OpenCompute (OCP) Caliptra is an effort by hyperscalers to enforce a platform root of trust with OSS firmware, mandating dual signature by server OEM and hyperscaler customer. The platform RoT is responsible for validating device firmware and OS boot.
> Often we see.. great security.. compromised by other great ideas for mgmt and other things.. starts to weaken its security posture.. want to keep Caliptra very clean [via OSS firmware transparency]
Isolation architectures like pKVM on Android can run banking or wallet applications in a security-controlled VM, alongside arbitrary user-defined VMs. In contested environments, both security and the freedom to innovate are necessary to survive an arms race with a competent adversary.
Personally, I have more trust in open source software than anything the vendor puts on their devices. But very often either the vendor software is only allowed to run, or you have to disable secure boot to run your own software, weakening your security.
So I would like to have a process where the actual end-user and owner of the device is the root of trust, and then transfer that trust to the vendor software or to their own software if they so choose, instead of having the manufacture, vendor or some agency be the root of trust. Of course, it can come with a sensible setup, where the vendor is already trusted, but that trust should always be revokable.
There should also be a way to remove or transfer the ownership to another person, if the device is sold.
pKVM goes in a different direction, where software that is run, does not trust the host system, which IMO is not very nice. Trust is something that goes both ways and need to be earned, if I put trust in a software and install it on my system, then I assume that the software also trusts me. If the software doesn't trust me, why should I trust it?
If there is no trust between us, then it should not run on my system but on someone elses and let me communicate with it via a well-defined API we can both trust.
Since this regulation is happening, necessary and welcome, it's good
to see some of the most respected FOSS groups taking the
lead. Hopefully many others representing smaller development
communities will join the Eclipse initiative. I would characterise
"Apache Software Foundation, Blender Foundation, OpenSSL Software
Foundation, PHP Foundation, Python Software Foundation, Rust
Foundation, and Eclipse Foundation" as BigFOSS. :) Joe Hacker
also needs a seat at this table.
> establishment of common specifications for secure software
> development based on existing open source best practices.
The problem with "best practices" is that there are always better
practices. Hopefully this group don't ossify around "best practices"
that are already out of date but become research focused. To be blunt,
a problem is not that "best practices" are never followed, but that we
have about 30 years of technical security debt to catch up with.
This foundation is also going to be a money pit, because it needs to
help other developers. It cannot rule, dictate or enforce anything.
Since most European devs are going to want to join in, it's going to
be paying out for conferences, education, development grants and
T-shirts. It'll need a pipeline of money from EU and commerce - and
there's the danger of corruption.
Whether they'd have something to contribute with their resources is a completely different question.
A bit of a tangent: FSF has a separate legal entity within the EU (https://fsfe.org/) which is (IMHO) way better at advocating than its American counterpart. There's also FSFI (India) and FSFLA (Latin America), but I'm unfamiliar with their work.
> I would characterise "Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation, and Eclipse Foundation" as BigFOSS
While names cited are associated to long-standing well-recognized projects, it strikes me at odd to include Rust Foundation here. Not only the language itself is still relatively new and used in few real life projects, but the foundation is very new (2021).
Moreover, looking at its last annual report, it spent half of it's budget (1.5M$) on "membership & admin". It seems like the true action of this foundation is to beg money from big corps and give it to a few selected members.
Here's[0] a breakdown from the foundation on that budget category. They also commit to breaking it down better in the future:
Salaries, benefits, payroll taxes, payroll service provider fees: $1.17m
Travel, event sponsorship, & support: $192k
Legal and Professional Fees: $66k
Fund transfer to the Grants Program from membership fees: $40k
Fund transfer to the Specification work from membership fees: $20k
Marketing: $36k
General Admin: (software, bank fees, meeting rooms, etc.) $20k
It's mostly salaries. They employ four engineers (software, security, infrastructure) that work on Rust, who they pay "at or above the average in their local market."
I guess the foundations are hyped because CRA basically forces companies to pay for security of OS projects (which the foundations try to be the main receiver of the money)
But in the end the OS ecosystem becomes much more secure.
Otherwise all the SV dudes complaining about the over burocratics: How to improve Software security? Only alternative I can think of, is the goverment pays for the security. For me thats a worser solution.
"Hyped" is not the word I'd use.
Most of us are or were concerned and it took a lot of long meetings to even move "us" out of the category of "software manufacturer" and into a new category of "steward" which is currently not well defined.
Also not hyped because the required standards are written at the EU level and there is no established process for foundations to participate in these standards.
So it's more like: Trying to do the best with the cards we've been dealt.
Suppose that applies to your open source because you are using a commercial split license and / or providing premium support or otherwise clearly commercialising the activity.
If you comply with all the CRA requirements (whatever they are) but the (free) USER of your software (user, not customer) gets hacked because of a security hole in one of your dependencies (that was not known) or a security hole in your own code (after all, is it possible to create something bulletproof) - are you liable for damages and what does it mean exactly in practice?
How does it differ from a situation where you offer proprietary software free of charge as a commercial activity? Can the right EULA protect you from receiving such damages. In order words, does it make the "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND..." well-known license even worse from the liability standpoint than a proprietary license agreement?
Would it not even invalidate those licenses since the license text cannot comply with the law? This is a big blow to open source. It does not matter whether it's monetised or not, open source is open source. They are messing with the definition. And to achieve what effect? The biggest cybersecurity problem that dwarfs all others combined and one that especially governments should worry about is the fact that memory vulnerabilities are everywhere, everything from the OS, the web browser and most popular GCed language interpreters are built on C++. And someone as determined as the people behind xz could probably bypass this regulation, if it could be of any help (obstacle to the attacker) at all in the first place.
It does potentially shut down a project I have considered commercialising (like, I may release, as "hobby open source" and dump it because I otherwise have no incentive to give my free time). If for every paying customer I am to be liable for 100 - 1,000 non-paying users, no thanks. Maybe I would not do it anyway, I have something else in sight, but I was very serious to experiment with it since I have most of it built anyway and it's just this opportunity to try it out as a side gig for a couple years, taken away by some bureaucrats. I have yet to do some more research on this (check my question in the second paragraph) but it does not sound like fun.
I'm thinking about Maw Gergel's Isopropyl book, and how in the 1960'sthey basically threw dangerous chemical waste out the window or buried it after a fire, scarring a kid.
That's the state of our industry today. In some ways, Open source seems among the better students of the class. In other ways, Open source is like a million people each contributing a few parts to a society critical factory, nobody noticing how big we grew. Of course that makes people uneasy.
I think something like this is unavoidable. How to get the max impact with minimal overhead is the most important discussion now, so I applaud apache's initiative.
Am I getting older? On a modern display... reading that text is awful.
Had to zoom it to 150%. At 'default' it's damn near 'fuzzy' looking.
Apache, omg, use a readable font and size for goodness sake.
It's text size 14px + a relative thin font + font with "serifs" + #404040; instead of black. Which is a gray which looks black but is 25% white.
I.e. thin small text of a font type which is well known to yield less good results on screens with unnecessary low contrast == bad UX.
Sadly way to many people today assume in their choices (sometimes without realizing it) everyone has mac book level HiRes OLED display and good eye sight where this should still looks quite fine (the contrast is better due to the screen, the font might lock wider due not using traditional sub pixel anti-aliasing, and the serifs aspect is less "bad" on high resolution displays).
But if you display it on a 1080p ISP display (assuming it's a decent 1080p ISP display) it will not be a very pleasant experience in a very subtle way due to lower contrast potentially thinner text and serifs in generally leading to decreased readability on non HiRes screens (hence why for years the general recommendation was not to use them for digital content).
At this stage there's only a few websites where I'd like reader mode off, really. It removes a lot of advertising, bypasses cookie modals, doesn't execute a lot of javascript, etc etc.
I wonder how long before we get browsers that run in readability mode first and foremost? O:-)
Slightly off topic but this is potentially a disaster for desktop apps and anything not SaaS. Correct me if I am wrong, the law requires to provide 5 years of security updates for apps. Some apps can leverage models such as "use it forever, but you only get updates for certain time without renewing". That allows companies *that ship apps where you can own your data* use a yearly subscription model and remain profitable. Now the desktop app vendor will be required to support users 5 years back, possibly shipping multiple builds (legacy versions with security updates and new version with features). Meanwhile the SaaS vendor charges a monthly fee and only has to care about security for the period of the subscription. I wonder how JetBrains is going to deal with that, I am pretty sure that their perpetual fallback is not updated for 5 years. But it's a big company, a small startup wanting to ship a desktop app will cry and despite the best intentions may as well change the direction to ship SaaS... The act provides the incentive to enshittify everything.
Readit News
This is the request which will allow the three european standardization organizations (CEN, CENELEC, ETSI) to draft the required 41 standards for the Cyber Resilience Act (CRA). See page 17 and following for the list.
To participate in the standardization you have to be part of a "national body" and they will "send" you to participate in EU standardization. I know no one from my FOSS circles who has any experience there, as most relevant standards for us are written outside of these organizations (W3C, IETF etc.)
So we're currently trying to get an official seat at the table via the established ways (e.g. DIN in Germany, https://standards.cencenelec.eu/dyn/www/f?p=CEN:5 see this for your own country).
If you are interested in this please send me an email, we're trying to put together a guide on how to engage in "official" standardization efforts as Open Source people.
The effort from this blog post is (amongst other things) trying to establish a whole new way of engaging with the EU. We need both approaches.
About your actual question: The answer is "not really" no. ETSI has a way to adopt existing standards: https://www.etsi.org/images/files/ETSI_PAS_Process_Guide.pdf But CEN and CENELEC (which are probably relevant here) do not.
The effort from the blog post is partially about a long term plan to get the EU to change this. But in the short term it'll be hard to change the rules in time for the CRA standards.
I really hope that we eventually get a mandate so that every device, that requires an internet connection for any and all features, will also have to allow the customer to overwrite and use their own software in case they have to make any software/security repairs themselves.
https://www.youtube.com/watch?v=p9PlCm4tLb8&t=2764s
> Often we see.. great security.. compromised by other great ideas for mgmt and other things.. starts to weaken its security posture.. want to keep Caliptra very clean [via OSS firmware transparency]
Separately, AMD has promised OpenSIL open firmware by 2026, https://www.phoronix.com/news/AMD-openSIL-Detailed
Isolation architectures like pKVM on Android can run banking or wallet applications in a security-controlled VM, alongside arbitrary user-defined VMs. In contested environments, both security and the freedom to innovate are necessary to survive an arms race with a competent adversary.
So I would like to have a process where the actual end-user and owner of the device is the root of trust, and then transfer that trust to the vendor software or to their own software if they so choose, instead of having the manufacture, vendor or some agency be the root of trust. Of course, it can come with a sensible setup, where the vendor is already trusted, but that trust should always be revokable.
There should also be a way to remove or transfer the ownership to another person, if the device is sold.
IIUC, OpenTitan is implementing this: https://opentitan.org/book/doc/security/specs/index.html
pKVM goes in a different direction, where software that is run, does not trust the host system, which IMO is not very nice. Trust is something that goes both ways and need to be earned, if I put trust in a software and install it on my system, then I assume that the software also trusts me. If the software doesn't trust me, why should I trust it?
If there is no trust between us, then it should not run on my system but on someone elses and let me communicate with it via a well-defined API we can both trust.
But it would be sad if I could no longer just buy a new off-the-shelf router and install OpenWrt on it.
> establishment of common specifications for secure software > development based on existing open source best practices.
The problem with "best practices" is that there are always better practices. Hopefully this group don't ossify around "best practices" that are already out of date but become research focused. To be blunt, a problem is not that "best practices" are never followed, but that we have about 30 years of technical security debt to catch up with.
This foundation is also going to be a money pit, because it needs to help other developers. It cannot rule, dictate or enforce anything. Since most European devs are going to want to join in, it's going to be paying out for conferences, education, development grants and T-shirts. It'll need a pipeline of money from EU and commerce - and there's the danger of corruption.
Any suggestions on organizations? These come to mind, but there must be others.
Free Software Foundation, https://www.fsf.org/
NLnet, https://nlnet.nl/project
SPI, https://www.spi-inc.org/projects
Software Conservancy, https://sfconservancy.org
Whether they'd have something to contribute with their resources is a completely different question.
A bit of a tangent: FSF has a separate legal entity within the EU (https://fsfe.org/) which is (IMHO) way better at advocating than its American counterpart. There's also FSFI (India) and FSFLA (Latin America), but I'm unfamiliar with their work.
While names cited are associated to long-standing well-recognized projects, it strikes me at odd to include Rust Foundation here. Not only the language itself is still relatively new and used in few real life projects, but the foundation is very new (2021).
Moreover, looking at its last annual report, it spent half of it's budget (1.5M$) on "membership & admin". It seems like the true action of this foundation is to beg money from big corps and give it to a few selected members.
[0]: https://rust-lang.zulipchat.com/#narrow/stream/335408-founda...
Otherwise all the SV dudes complaining about the over burocratics: How to improve Software security? Only alternative I can think of, is the goverment pays for the security. For me thats a worser solution.
Also not hyped because the required standards are written at the EU level and there is no established process for foundations to participate in these standards.
So it's more like: Trying to do the best with the cards we've been dealt.
I agree wtih everything else you're saying.
If you comply with all the CRA requirements (whatever they are) but the (free) USER of your software (user, not customer) gets hacked because of a security hole in one of your dependencies (that was not known) or a security hole in your own code (after all, is it possible to create something bulletproof) - are you liable for damages and what does it mean exactly in practice?
How does it differ from a situation where you offer proprietary software free of charge as a commercial activity? Can the right EULA protect you from receiving such damages. In order words, does it make the "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND..." well-known license even worse from the liability standpoint than a proprietary license agreement?
Would it not even invalidate those licenses since the license text cannot comply with the law? This is a big blow to open source. It does not matter whether it's monetised or not, open source is open source. They are messing with the definition. And to achieve what effect? The biggest cybersecurity problem that dwarfs all others combined and one that especially governments should worry about is the fact that memory vulnerabilities are everywhere, everything from the OS, the web browser and most popular GCed language interpreters are built on C++. And someone as determined as the people behind xz could probably bypass this regulation, if it could be of any help (obstacle to the attacker) at all in the first place.
It does potentially shut down a project I have considered commercialising (like, I may release, as "hobby open source" and dump it because I otherwise have no incentive to give my free time). If for every paying customer I am to be liable for 100 - 1,000 non-paying users, no thanks. Maybe I would not do it anyway, I have something else in sight, but I was very serious to experiment with it since I have most of it built anyway and it's just this opportunity to try it out as a side gig for a couple years, taken away by some bureaucrats. I have yet to do some more research on this (check my question in the second paragraph) but it does not sound like fun.
That's the state of our industry today. In some ways, Open source seems among the better students of the class. In other ways, Open source is like a million people each contributing a few parts to a society critical factory, nobody noticing how big we grew. Of course that makes people uneasy.
I think something like this is unavoidable. How to get the max impact with minimal overhead is the most important discussion now, so I applaud apache's initiative.
I.e. thin small text of a font type which is well known to yield less good results on screens with unnecessary low contrast == bad UX.
Sadly way to many people today assume in their choices (sometimes without realizing it) everyone has mac book level HiRes OLED display and good eye sight where this should still looks quite fine (the contrast is better due to the screen, the font might lock wider due not using traditional sub pixel anti-aliasing, and the serifs aspect is less "bad" on high resolution displays).
But if you display it on a 1080p ISP display (assuming it's a decent 1080p ISP display) it will not be a very pleasant experience in a very subtle way due to lower contrast potentially thinner text and serifs in generally leading to decreased readability on non HiRes screens (hence why for years the general recommendation was not to use them for digital content).
In other words: Turn on display scaling instead of expecting every website to increase the font size.
I wonder how long before we get browsers that run in readability mode first and foremost? O:-)