EU Cyber Resilience Act and RISC OS

To everyone interested,
As we navigate the evolving landscape of cybersecurity new regulations, it’s potentially crucial to discuss the forthcoming EU Cyber Resilience Act and its potential implications for RISC OS. The Debian Project has recently shared insights on this matter, which could significantly impact open-source software, including our own platform.

I strongly encourage both the RISC OS Open Ltd and RISC OS Developments Ltd teams, as well as community members, to review Debian’s statement and consider the possible effects this regulation may have on RISC OS. This regulation is poised to affect the entire open-source ecosystem, making it vital for our community’s key stakeholders to assess and prepare for any potential challenges to the free distribution and development of RISC OS.

You can find Debian’s detailed statement here:
https://bits.debian.org/2023/12/debian-statement-cyber-resillience-act.md.html

I urge all interested parties to read through this document carefully before contributing to the discussion. Your understanding and insights are invaluable as we collectively navigate these regulatory waters. I am not a lawyer, so I may be overlooking important elements, hence I thought it would be a good idea to share this and see what others think about it.

Why this post? Well as per definition of the Linux Foundation:

“At its core, the CRA puts its obligations on software manufacturers: those who publish code that is available in the EU. This base category essentially covers anyone who publishes software on the Internet, open source or not, regardless of whether you’re in the EU or not – as you would likely have EU users.”

So, my limited understanding, suggests that it will have an impact on RISC OS.

As a side note: I have been tirelessly working on enhancing the infrastructure within the RISC OS Community on GitHub. This effort aims to analyze every piece of code we produce and distribute, ensuring compliance with not only the forthcoming EU act but also any similar regulations that may arise in other jurisdictions like the US.

Looking forward to a constructive and informed discussion and hope my English was clear/understandable enough.

[edit]
changed overseeing with overlooking, my mistake
[/edit]

It’s my understanding that this relates to products being sold within the EU. It doesn’t cover “free” and it also doesn’t appear to cover “software as a service”.

Clause 10 says:

(10)In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

[full text: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454]

I can see sort of what they’re trying to get at with this act (like that shiny new phone never getting updates, or that webcam with security holes big enough a preteen could figure out how to get in), but it is an incredibly overreacting arse backwards way of doing it that risks causing device manufacturers to say “sod it” and just ditch the EU market, while we’ll still be flooded by endless amounts of Chineseries that are the real problem yet nobody seems interested in doing anything about.

Well intentioned, but seems like a potential killer for small businesses / orgs. At a brief glance it doesn’t appear to demand the extraterritoriality claimed by GDPR (i.e. applying to EU citizens located outside the EU) but might require people in my position shutting off supply of goods to folk in EU SM.

I’m wondering about my Mamie game. Granted, there’s zero security in it… but it is an entirely self contained game that doesn’t serve anything, doesn’t attempt to contact an outside server or receive connections from one, doesn’t hold/request/manipulate personal data…
…so what the hell is the point of a cyber ¹ resilience act on something that isn’t cyber ¹? The only cyber ¹ part of things is the way in which you obtain the game, and that’s not my responsibility. I don’t see the point in wasting time and money that I don’t have on something that is fundamentally uncertifiable. The only certifiable part of all of this is me. ;)

¹ I hate that word, it should have died an honourable death at the end of the 90s. “Cyber” to me basically translated as “somebody attempted to read a William Gibson novel but didn’t understand a single part of the story”.

“Cyber” to me basically translated as “somebody attempted to read a William Gibson novel but didn’t understand a single part of the story”.

It sits in the same family grouping as ICT (instead of IT) and other bovine characterised labels and buzzwords.

It sits in the same family grouping as ICT

Why the hatred for International Computers and Tabulators? Admittedly I had to deal with the products of their successor company for the majority of my working life, but they weren’t that bad.

Sorry, off-topic. I’ll get my coat…

I’m wondering about my Mamie game. Granted, there’s zero security in it… but it is an entirely self contained game that doesn’t serve anything, doesn’t attempt to contact an outside server or receive connections from one, doesn’t hold/request/manipulate personal data…

But the question then becomes, can someone remotely execute your game and cause it to open a hole that can then be exploited by something else.

And all this because companies freely grab open source code, cram it into their commercial and publicly exposed offerings without any sort of scrutiny, let alone any further maintenance requirements until something horrible goes public, log4j and openssl vulnerabilities come to mind.

And all this because companies freely grab open source code, cram it into their commercial and publicly exposed offerings without any sort of scrutiny, let alone any further maintenance requirements until something horrible goes public, log4j and openssl vulnerabilities come to mind.

Then, when they are medical equipment suppliers they respond with “the FDA¹ won’t allow…” when pressed about creating/applying a required fix² – in the log4j instance an authority closer to home gave a JFDI instruction to the suppliers.

¹ Quite what the Federal Drug Authority has to do with non-USA use I have no idea.

It’s my understanding that this relates to products being sold within the EU.

Yes, like ePic and DDE, as well as some of the software in the PlingStore and some of the Apps still being sold on the internet like !Organizer etc.

Given RISC OS can’t be made secure (at least with the architecture it has now), it’s going to be hard to keep all these tools and games on sales (if I understand the regulation correctly).

As mentioned by Stuart:

might require people in my position shutting off supply of goods to folk in EU SM.

I have the same feeling.

I am not sure also how this will impact hardware manufacturers, given also Linux (which could be used as an escape for RISC OS compatible devices), will put burden on them.

Quite frequently the fix has existed for months/years but hasn’t been applied because “the FDA won’t allow…” the truth being more to do with the cost of submission to the FDA, even where the FDA do have authority.

Or FIPS for FIPS 140-2 modules, because every change is a resubmission.

can someone remotely execute your game

If that’s possible then it’s either your fault (ie an unsecured VNC session) or you have far bigger problems.

and cause it to open a hole that can then be exploited by something else.

It shouldn’t be possible as there is no external “opening” of anything going on. There are only three external files used by the program:

• The audio files, because RDSP needs to be able to load them itself (and/or the sample player for the MP3 title theme). All handled by third party code.
• The advert JPEG for the nod to AmCog’s Haunted Castle. Handled by the OS JPEG plotter.
• The level data file (if it exists). Parsed as text to build the game maps.

I guess the ubiquitous nature of everything spewing data to the mothership is where these holes are turning up… but what about those things that, like, don’t?

In my case, it’s not a server nor a client. It exposes no interfaces that would provide or accept data from a remote source. Effectively, in order to do anything with Mamie, you’ve already been pwned.

let alone any further maintenance requirements until something horrible goes public

Even then, you’ll only see something done if it’s important. If it’s a Chinese box shifter, you won’t even get a reply, never mind a fix.
Here’s a real life example: https://heyrick.eu/blog/index.php?diary=20170617

it’s going to be hard to keep all these tools and games on sales (if I understand the regulation correctly).

I expect that it will be introduced with the usual back-patting fanfare, the excrement will then hit the fan, and all sorts of creative exceptions will be made… eventually making the legislation being well-meaning but ultimately about as useful as all that cookie crap.

Cookie crap? Check your browser sometime. According to CNIL (the French DPA), cookies cannot be placed onto a system until the user has given consent. I’ve just gone to La Figaro (randomly chosen as the only non-local French paper I remember the name of (because Queen ;) )). A popup has appeared as expected, however there are 19 cookies already stored. Maybe technical, but still…
It gets worse. Article 4 of the GDPR says that consent should not be considered to have been given freely if the person concerned does not have a real freedom of choice or is unable to refuse or withdraw consent without suffering detriment.
Well, Le Figaro gives me a choice here. Accept all cookies and the adverts/tracking, or subscribe. How is this legal? It’s the same for Marmiton (recipes).

Don’t get me started on the “legitimate interest” bollocks and the many sites that have an easy “Accept all” button, but expect you to manually turn off “Legitimate interest” for some three hundred “partners”.

In short, the legislation is crap and the best way to deal with all of this is to have a script that hides the cookie popups, and another that goes out of its way to intentionally scramble the tracking cookie data.

I can imagine this law will also be about as useful.

I have the same feeling.

Thankfully nearly all of my software is non-commercial, so I don’t have to worry about this as nothing is being “sold”.
I am going to leave Mamie on Store for as long as Store remains operating. The EU is welcome to fine me, what is it, 20% of my annual turnover? Well, I think I’ve sold about ten copies and I’ve let R-Comp keep the royalties as a (meagre) donation to RODev (it’s also a hell of a lot less of a headache than trying to work out how to include it in my tax declaration).
So, 20% of zero is what, exactly?

I’ve speed-read the proposed legislation (it’s the usual mouthful), but what strikes me is that it would have made a lot more sense to restrict the primary application of this legislation to “software that is supplied within an actual thing” (aka firmware). This way it would cover printers, phones, all that Chinese tat, and so on but have less of an impact on user sourced software (such as Microsoft Office, anything on Store, mobile apps, games on Steam, etc etc) which aren’t so much baked-in firmware but a specific user choice to install. Plus, these sorts of things do tend to be updated whereas firmware is less frequently updated. My Mi10T (2 years old) is running MIUI 12 with Android 10 security patch level 2021/02/01. It received a small update shortly after I bought it, and nothing since. My newer Redmi is running MIUI 14 with Android 13 and patch level 2023/11/01 (it started with MIUI 12) having several updates recently – but will there be any more? This is where the problems lie.

Perhaps moreso with Apple than Android as, last I knew (iOS7ish) the browser and mail clients (etc) were part of the firmware release and not something that could be updated seperately. However, unlike most Android makers, Apple do support their hardware for some time.

Anyway, in the domestic domain, it’s the baked in code that’s the problem. Not the plethora of apps kicking around.

Quite what the Federal Drug Authority has to do with non-USA use I have no idea.

America runs the world, or something.
At work, the water hoses in the production area are stamped with an FDA approval. <shrug>

That being said, I don’t know about the new part of the factory, but the older part had much of the plumbing in imperial measurements because apparently it was cheaper to buy metal pipework in the US and get it shipped over here, than to buy French metric sized pipes. <double shrug>
(granted, the maintenance guys could have been pulling my leg, but the pipes are marked something like 3/4").

Or FIPS for FIPS 140-2 modules, because every change is a resubmission.

Oh, it’s all about money.
Which strikes me as strange, since they happily charge silly large figures for client devices in data capture setups that are, at base, a Raspberry Pi in a plastic box.
It’s nothing new, 30+ years ago the component parts for some kit totalled about £30 and the purchase price was over 20 times that.

Yes, they have to re-submit, but the cost of that is small in the grand scheme of (over)charging.

Looking at this from a security engineering point of view, I think there’s some things that could be done:

1. Setting out a statement of what security RISC OS does and does not offer you. There are things ‘we all know’ around here, but it would be useful to have them written down so nobody is using RISC OS under a misapprehension
2. A private vulnerability reporting mechanism where people can report problems. At present there’s not really any way to do that, especially for third party software
3. A disclosure mechanism where discovered vulnerabilities are published along with updates
4. A resource of best practice (either documentation or people) of how to do things

On point 4, I’d had discussions with vendors who didn’t know anything about security and couldn’t see why their software was faulty.

One past example would be ‘the BCH cryptosystem’ that shipped with the Iyonix. This was basically snake oil crypto, but finding an exploit was more work than I had time for. I know of other software in current use that fits into a similar category – it’s badly engineered and appears vulnerable but neither I, nor seemingly anyone nefarious, have the time and energy to break it in order to show the author the problem. Maybe the payoff for successfully breaking something is so low that nobody is bothered and this counts as a win?

so nobody is using RISC OS under a misapprehension

Easy: RISC OS offers the SWI OS_EnterOS that will happily give any bit of software kernel level privileges. Thus, RISC OS cannot be considered “secure” in any meaningful interpretation of the word.

A private vulnerability reporting mechanism […] A disclosure mechanism where discovered vulnerabilities are published

Given the fundamental architectural problems, the slowness of updates, and the fact that this is pretty much a volunteer-based project without “big commercial backers”, is it actually wise to publish what would essentially become a “How To” for hacking the OS and its software?

discussions with vendors who didn’t know anything about security and couldn’t see why their software was faulty.

The complete apathy of the various national regulators is partly to blame here. It’s always easier for vendors to ignore a problem when there’s no repercussion for doing so. I think this proposed legislation is an overreaction to the fact that nobody did anything for far too long.

I’m not sure what the actual best solution would be. A crappy webcam is in a different league entirely to medical equipment, for example. And this is only considering devices with built-in firmware, while this legislation appears to want to try to regulate more than that, so I don’t know if a “one size fits all” is the way to deal with this…
…unless this is a secret ploy by the EU to try to find ways to ban most non-EU devices in favour of approved EU-made ones? Uh-hu. What EU-made ones?

I know of other software in current use that fits into a similar category – it’s badly engineered and appears vulnerable

Sadly, most of the designed-by-committee WiFi protocols fall into this category ¹, and there’s a use in breaking them.

Maybe the payoff for successfully breaking something is so low that nobody is bothered and this counts as a win?

The expression is “Security by obscurity”. Something either badly designed or designed before security was even a thing ², but so trivial and unimportant that nobody bothers. I’m afraid pretty much anything to do with RISC OS falls straight into this category.

It’s nothing new, 30+ years ago the component parts for some kit totalled about £30 and the purchase price was over 20 times that.

At work we have a big machine for prewashing, washing, then drying the baking trays that we use. It’s the one I’ve mentioned on my blog that can suck over a hundred kilowatts when it’s running flat out. One of the maintenance guys once described it as “sixty grand worth of parts in a box that cost ten times that”. The idea of sticking some relatively ordinary stuff in a box and charging a lot for it isn’t new – just look at Apple kit. ;)

¹ Whoever thought it was a good idea to split the WPS key into two independent halves should be taken out back and shot.

² Those halcyon days when it was perfectly okay to send user passwords down the wire in plain text in an educational environment because nobody would go looking ² to collect other people’s passwords.

³ Wrong! (it’s why I first learned ARM code ☺)

I think this proposed legislation is an overreaction to the fact that nobody did anything for far too long.

I think it’s a reaction to the poor defenceless EU markets being flooded with “cheap crap” from Chinese companies that often seem to last only as long as it takes to make a product and ship it.

Those halcyon days when it was perfectly okay to send user passwords down the wire in plain text in an educational environment because nobody would go looking

Well, none of us did, we’re far too nice :)

Nope never, ever, ever.

¹ Fiddling around in Windows registry to fix a programme, that ceased working when transferred from Win95 to NT, and “accidentally” breaking the software protection (that was the bit that failed)
Fiddling around on the password file of the door access system, figuring out the encoding and raising the access level of in-house users to engineer level
Fiddling with software protection to allow editing to fix a string length error.

The (network) security features of current RISC OS aren’t exactly Ft. Knox- like in the"bottled up tight" category, are they? Do they exist at all? If not, are there programming teams capable and able to rectify the situation before this Act is in effect?

This is what the regulation mention directly:

“This Regulation applies to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.”

Cit. Article 2, Scope, bullet point 1

This is the definition of product (for the regulation):

“‘product with digital elements’ means any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately;”

Cit. Article 3, Definitions, (1)

So, according to these two citations, even RISC OS itself (even when free) will be subject to the regulation as the definition of product doesn’t specify paid or free, just introduced on the market basically.

Looking at this from a security engineering point of view,…

So, before we get into the Cyber Security engineering details, I think the major impact of this regulation will be in the processes and methods it requires vendors to adopt, which for an almost non-existent market (given its ridiculously small size) as RISC OS market, will put a lot of pressure on the “family-sized” Ltds that exist.

Given the definition above, it may even become a deterrent to the “for fun only” side of RISC OS.

The regulation comes with good intentions, as mentioned, it’s mostly aimed at vendors that have been exploiting customers for years and to side-chain attacks that constantly undermine security and privacy of user’s data. So, let’s be clear on this, it’s a good move, but the impact on small business could be substantial.

as the definition of product doesn’t specify paid or free, just introduced on the market basically.

Clause 10:

Therefore, RISC OS as supplied is exempt. Putting RISC OS into something and then selling that something would make that thing call under the CRA.

as RISC OS market, will put a lot of pressure on the “family-sized” Ltds that exist.

Question 1: Is anybody selling a product with RISC OS inside? I’m aware that there is some sort of product (after all, who sponsored the IPv6 stack?), but on the open market, I’m not aware of anything (discounting an ancient emulator with an equally ancient version of the OS, that’s the other one, not our problem).

Given the definition above, it may even become a deterrent to the “for fun only” side of RISC OS.

Certainly it might be an issue for application development, but the open source “for fun” stuff can continue. Whether or not free non-open software can continue is a question.
For something that’s supposed to be legislation on software security, it is about as well worded as the GPL. Case in point “buying or using products or software with a digital component”. What the hell is “software with a digital component”? For the love of god, get a nerd to write this, not a committee who probably can’t use anything beyond PowerPoint.

The regulation comes with good intentions

The road to hell is paved with them.

it’s a good move

It’s a lot like the EU in general. A good idea, but the actual implementation leaves a lot to be desired.

This proposal is too wide reaching and too unspecific; when it comes to pass it could have unpleasant side effects to a lot of software development and devices within the EU (expect your prices to rise in inflation busting ways) etc etc. Maybe at some point in the future it’ll be tamed, reined in a bit, but after causing what damage to the industries concerned?

All the while, the very shit they’re trying to stop will continue to be flooded across Amazon, eBay, Alibaba, Temu, etc. Only now it’ll all carry a little “CE” marker that technically means “China Export” and just happens to coincidentally resemble the actual CE mark…

In other words, while this is a laudable proposal, I can’t help think that we’re going to end up screwing ourselves rather than actually doing anything much about the problem at hand.

Question 1: Is anybody selling a product with RISC OS inside?

For a start over here there are commercial products that support RISC OS development (and this site), let’s start with RISC OS ePic.

And the guys who build wee systems that ship with RISC OS, such as RISCOSBits, the former ARMbok…

Could be worse, after all some folk ship dual-boot systems so have to worry about Linux as well as RISC OS.

For a start over here there are commercial products that support RISC OS development (and this site), let’s start with RISC OS ePic.

And the guys who build wee systems that ship with RISC OS, such as RISCOSBits, the former ARMbok…

Yup

And it’s not just that, what about software built “with” or “on top of” DDE, BBC BASIC, libraries etc. The open letter from Debian clearly state the problem.

On top of that there are also concerns on the funding and sponsorships (aka ROOL’s bounties and ROD founded projects like the network stack or Pinboard 2, Iris):

https://www.eff.org/deeplinks/2023/05/eus-proposed-cyber-resilience-act-raises-concerns-open-source-and-cybersecurity

So, it does not appear a simple issue

commercial products that support RISC OS development

Which, of course, makes the situation a lot more complex. After all, RISC OS itself is free and open source, but…

such as RISCOSBits, the former ARMbok…

Fair point. I was thinking more of “devices with RISC OS inside” rather than personal computers.
After all, is Dell/HP/Lenova/etc going to claim compliance for shipping machines with Windows pre-installed? What about a Linux option?
How much would that add to the price tag while changing little?

So, it does not appear a simple issue

Like I said, good idea lousy implementation.

So, it does not appear a simple issue

QEMU on a secure OS.
Yeah, getting the right set of QEMU initiation parameters isn’t easy.

However, when you figure that out:
What machine would you like to emulate?
Sabrelite
Pi1
Pi2
Pi3
Pi4
A more generic ARM board

Like I said, good idea lousy implementation.

That’s what happens when you have the Euro-nitpickers take up their grumbles and walk – no proper critical thought process.

Without changes to QEMU, the only suitable machine I am aware of is the Pi2 OR that monster-Pi I configured in the other thread.

But, I am afraid, running RO on QEMU won’t solve the issue. The problem is WHERE we store personal data. So, if we do everything on RO, then the whole game is played on RO, QEMU is not relevant, nor the secure OS under it, our data can be stollen anyway, our CC read, our emails sniffed, our desktop environment infected etc.

What could work is something that runs Apps in a QEMU isolating them from RO for example. But, hey, with the number of people we are… that is a sci-fi-level goal! Unless, I make my Hypervisor work with RO and then partition per App, which means the Hypervisor should also integrate the desktop experience (same if using QEMU)… ermmm Steve, that’s a loooooot of work my friend ahaha I’ll need to retire earlier and focus on working non-stop on that only to get something done within the time-frame we are all still alive!

Jokes apart, to be compliant with the regulation we would need to implement compartmentalization between RISC OS Apps, which requires emulation because the Apps for RISC OS are designed with the assumption of working on a pseudo BBC Micro environment. So, expect an App to do whatever they want and know the OS doesn’t copy data blocks between the App and the kernel, there is direct access both sides, so that needs to be re-thought / re-designed from the ground app, aka de-BBCMicro-ify RISC OS (if you prefer word games) OR it needs to be left untouched and remove the kernel from EL1 and move it to EL2.

Like I said, good idea lousy implementation.

I am not 100% sure if it’s truly “lousy” or more the result of lobbying. You know, corps will be perfectly fine with that process, the small business however not so much. Looks like an already seen pattern, many, many times. But oh well, it is what it is…