EU Cyber Resilience Act and RISC OS

I am old enough to remember systems analysis.

@ Simon

Nobody expects civil engineers to move a bridge 20m to the left

Ermmm actually that HAS happened sometimes, or in house projects need to do changes because the land isn’t fully as expected for foundations or there isn’t enough space (calculus mistakes) for external stairs etc… but ok I’ll give you that :)

Agile is not knowing exactly what your customers want (because your customers never know exactly what they want)

Isn’t that the definition of not knowing what one is doing? ;)

but converging on a solution that is what they want with the minimum of wastage.

In most cases Agile is a process for both the engineering team AND the customer to both BUILD and EXPLORE a solution to a problem. SO yes it’s based on the fact that both the two entities may have no idea of what to do. HOWEVER, this is were good Agile comes into play, normally an engineering team should evaluate customer’s Assets to ensure considering them accordingly to their real world priority (this indeed resemble, although if partially, traditional water fall analysis, but it has a very well defined focus and, most of all, completion), and then try to start from designing software that mimics the existing customer’s process and then (later on) optimizes it, which is another important element to avoid the famous over-engineering situation. In other words start simple by following what the customer already does and by doing so learn and then improve.

And besides, if Agile wasn’t designed to be an explorative process for both sides, it would take us much longer to train a teams of software engineers to become confident of every new specific problem domain AND have customers having internal revision processes to understand exactly what they want and need and present it in a discrete form. So, it’s not necessarily a bad thing, it’s intended to be a way to proceed forward even if we are not very sure of where we should be heading to.

All the above is doable and well defined. A good Agile process has few rules and is not an over complicated process that will inexorably lead to a “masked water fall”. But determining what an MVP can be in such a scenario can be extremely difficult, and so, even if an agile process can be applied and the invaluable constant feedback from a customer could be implemented successfully, the determination of “ok I can start working with this” is going to be extremely hard to be planned and provide an ETA, hence the “do it quickly” won’t work with Agile.

On top of all this there is the eternal: Remember what a customer wants is not always what they need. Hence it’s very common to have an “explorative approach”.

But again, if I was wrong, then we wouldn’t have still such a high % of projects failing…

I am old enough to remember systems analysis.

I had this too, we had analysts in some of the early teams many years ago. Then it was the time of Architects. Now we are in the age of shared architecture where multiple members of a team are expected to take architectural decisions. It’s an interesting evolution, and yet certain applications made long time ago are still in production to this day and age…

Isn’t that the definition of not knowing what one is doing? ;)

No. It’s like saying your taxi driver doesn’t know how to drive because you haven’t yet worked out what your destination is.

Lots of projects, both software and traditional engineering, fail. The difference is that the latter is usually building on decades, even centuries, of knowlege. How much does the design of a motorway bridge differ from those made 50 years ago, or a Roman viaduct? Compare that to how much the design of a user interface from even a decade or so ago, when touch screens were rare and flakey.

No. It’s like saying your taxi driver doesn’t know how to drive because you haven’t yet worked out what your destination is.

Oh I see you’re confusing your technical skills with the knowledge of the problem domain. So with the example of the taxi driver, that means he knows how to drive a car, but he has no idea WHERE you want to go and so he has to proceed in steps and verifications in order to understand if he is going in the right direction.

In the same process, the customer, by looking at the area may understand if it’s the wrong path OR if it’s actually a better path than the one he was originally thinking of.

Hope this makes more sense.

In an Water Fall approach, both you and the taxi driver would plan the path ahead of time and consider all possible issues along the way, like traffic congestion if you pass by road X or engineering works if you pass by road Y and so on and so forth, so the journey would start only when all the considerations are done and you both agreed on the best path.

[edit]

This BTW is why Refactoring is so important in Agile and it’s so important that many Agile experts consider it part of the activities, not a separate thing.

And Testing is another very important aspect of modern Agile methodologies like BDD and TDD etc. or the slightly older ones like Extreme programming and all that plethora of things people used to write books about.

[/edit]

[edit 2]

Added the definition of some of the acronym I used in my comment for the folks less into software development methodologies

BDD = Behavioral Driven Development
TDD = Test Driven Development
XP = Extreme Programming

[/edit2]

This is actually an exciting chat :)

Another “traditional” element of Agile methodologies are patterns, from design patterns to service patterns and architecture patterns. They all represent the true experience and knowledge high profile developers gain over time in a continuous Agile workplace.

Those are all re-usable elements, which become fundamental, when someone realize that the true “knowledge” in Agile is knowing that Requisites WILL change. And so the personal focus shift towards understanding how to reuse components and becoming better and faster at “steering the wheel” towards new directions. And patterns are one of the best tools to do this (as long as one doesn’t fall in the trap of over engineering which is an easy trap to fall for in Agile, given code can be discarded at any time if requisites change a lot).

In modern CI/CD this becomes even more important, ’cause continuous changes are applied and they are supposed to offer continuous delivery as well, some companies deliver multiple times a day.

[edit]

Also on this one adding meaning of tech acronyms:

CI = Continuous Integration

CD = Continuous Delivery

Refactoring = Improving your original code over multiple iterations to clean it up, reorganize it, make it more readable and optimizing it for memory and/or performance

[/edit]

plan the path ahead of time and consider all possible issues along the way

That’s me. I considered so many particle mishaps that when I needed to be in Rennes at 1pm to get my residency permit, I was there for half ten.
My plan also included insurrection and zombies, which pretty much boiled down to “run away” but did require me to spend time with Google Maps to familiarise myself with the area so I could go from the train station to the hospital overground-underground and around some pathways and back roads to the prefecture from memory without needing a map (and knowing where the side roads would take me in case of uprising or zombies).

You probably think it’s weird, but for me, if I haven’t considered the possibility of the dawn of a zombie apocalypse then I just haven’t planned my plan enough. It should be straightforward both in normal execution and in crisis mode.

By way of example of the opposite, when I went to Nantes. That was not at all planned, I just drove to Chateaubriant, got a train ticket, arrived in Nantes. Found the giant elephant (eventually), found the Jules Verne museum (by accident), and got rescued more than once by locals speaking to me in English telling me what tram I should be on (which wasn’t the one I was on). Next time I’ll absolutely need a map!
I don’t regret it. A lot of walking but a really nice day out. But, oh my, it needed a plan.

Unfortunately, I write software like Nantes, not like Rennes. There may well be zombies lurking in the code, but since the OS my stuff runs on practically is the living dead, that’s okay.

In modern CI/CD this

The reason I’m nonplussed about these new paradigms is that they may be varying levels of good/useful from a programming viewpoint, but from a user viewpoint it often boils down to “throw something out the door, the users can be the beta testers, we’ll fix bugs as they get reported”. Not only is that time wasteful and annoying as a user, it becomes a much larger problem when these fixes fail to materialise.

If the CRA requires vulnerabilities to be declared, well, might want to read “something else AI has screwed up”: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

@Paolo
Does the buzz phrase collaborative design mean anything to you?

This https://math.ucr.edu/home/baez/act_course/lecture_65.html may perhaps not be to your taste, but I guess that a lot of the Agile concepts can be made mathematically rigorous.

You probably think it’s weird,

Not at all.

Does the buzz phrase collaborative design mean anything to you?

may perhaps not be to your taste, but I guess that a lot of the Agile concepts can be made mathematically rigorous.

Oh nice stuff! And yes I have met some folks who mentioned the same. While I am very interested in the link (so thanks for sharing), I also think that Agile has become another buzz word over the years. So, it now means nothing or everything, some companies uses traditional approaches and calls them Agile, others use the term Agile to just say “give me something to sell ASAP”, so my world is so much full of buzz words…

This year cyber security dictionary of words is 116 pages full of acronyms invented mostly by companies to sell stuff and to look professional in most cases… bah…

I don’t think I was confused, as such, but I think we’re on the same page, now!

An agile approach is essential when there isn’t a map available. Exploring the problem space, as it were.

I know a company where their idea of Agile is a progress meeting every morning, and I know that’s not unusual (my partner trains people in project management for a living). The last major project I worked on had a folder of requirements several inches thick defining everything from the radio frequencies to be used to the height and colour of buttons on the screens. None of it made sense until we came across a very simple diagram of how the satellite system was meant to work!

Now I think about it, I’m not sure they specified what buttons should be on the screen.

Thanks, Gavin, for the reading assignment! It looks interesting.

And Testing is another very important aspect of modern Agile methodologies like BDD and TDD etc. or the slightly older ones like Extreme programming and all that plethora of things people used to write books about.

Testing has been an important part in pretty much all software development processes since the dawn of time. But as with many things, the Agile/Scrum/XP guys pretended that this is a new idea while they were just reinventing the wheel one more time.

Maths is just a tool for understanding the world. Sometimes a tool is developed to address a specific problem, but more often it is developed for quite other reasons, and it is only later that it is used to solve a problem. Category Theory is a tool for understanding maths, so that Applied Category Theory is a phrase that begs a lot of questions. I feel that I should be apologizing for bringing it up on this forum, but Computer Science is an area where Category Theory has been fruitfully applied.

Now I think about it, I’m not sure they specified what buttons should be on the screen

but you knew what colour they were going to be, which is obviously more important in certain peoples minds. :(

None of it made sense until we came across a very simple diagram of how the satellite system was meant to work!

I’ve lost track of the number of times I’ve asked something where I could see how it might, possibly, require what I was being told to do, and then after looking at an annotated diagram and a couple of paragraphs it became clear that the other stuff was “fluff” and so I could give them what they needed – not what they asked for.

Testing has been an important part…

True, but it used to be a separate department, not the developers writing the test before the code. (TBH, I’ve never got the hang of that!)

you knew what colour they were going to be

I might have been being a bit unfair, there. I was working on communications testing software, not the user interface. If anyone’s interested, it was part of Meteosat Second Generation, and I just learned a bit more about it from this video.

https://www.youtube.com/watch?v=SSjjoa7ILpw

the Agile/Scrum/XP guys pretended that this is a new idea while they were just reinventing the wheel one more time

Ermmm please let’s avoid these unfounded and personal opinions.

Here is a brief history of Software Testing (and WHEN it became an important part of..):

https://www.geeksforgeeks.org/history-of-software-testing/

To be clear, no one in the modern Software Engineering claims they invented software testing or want to take credit for ALL the software testing techniques invented over the years. But, as pointed out well by Simon, with modern Software Development methodologies Software Testing became part of the developer process and not anymore an “added” process.

In case of doubt, or for a more practical approach and “who should do what” in software testing, I also published a concise article that describes all the phases/techniques, lists some tools and testing frameworks, provides practical examples and helps the reader understanding how to implement their code so it can be “testable”, article here:

https://paolozaino.wordpress.com/2021/06/20/software-development-introduction-to-code-testing/

Yes all concepts applicable also to RISC OS developments. I also ported/adapted to RISC OS some good testing frameworks for C that works with both DDE and GCC, links to download them to try them out here:

https://github.com/RISC-OS-Community/GreaTest

https://github.com/RISC-OS-Community/mUnit

The last major project I worked on had a folder of requirements several inches thick defining everything from the radio frequencies to be used to the height and colour of buttons on the screens.

Ha, been there quite a few times. But, in the other hand I have also been in “Agile” projects were Product (department) didn’t understand the customer, so the results were… well… a constant refactor out of customer complaining that we did not implement what they wanted. Like at every single review ahaha, at some point Management finally figured out that Product wasn’t as good as they should have been, but it was too late for the project.

None of it made sense until we came across a very simple diagram of how the satellite system was meant to work!

Painful! But yes sometimes a diagram can work wonders! And other times we can get into the (now) famous “leaky abstraction” phenomena where abstraction causes troubles, but luckily leaky abstraction problems are not as common as problems caused by extremely lengthy BRDs water fall style.

Ermmm please let’s avoid these unfounded and personal opinions.

I think I know the kind of thing Steffen is referring to.
I was concerned by the apparent rehashing of content by different theorists, so, a bit over 35 years ago, I challenged my management theory lecturer to identify the specific management theory from author A, B, C that I was paraphrasing.
By changing the style of phrasing I had him label three different sets of text as three different authors, the original was in fact the same in every case.

When I showed him what I had done, he went away and re-examined the “originals”. You could call it copying (he did), but most people label it plagiarism.
The content is often valid, although most of it is the thing that isn’t common = “common sense”

The content is often valid, although most of it is the thing that isn’t common = “common sense”

Indeed. Often we find on software development methodologies books reference to old practices and how they should have been integrated in the daily activity and why it’s important to write code that is “testable” vs a full chunk and then let it be tested by others in whatever extent they can.

Just to be clear, my response was to Steffen, not Simon BTW.

Just to be clear, my response was to Steffen, not Simon BTW.

My error. I will claim distraction, I had a plumber in fixing a faulty shut-off valve for the washer feed. Post edited.

However, the fact is there is a lot of rehashing in the management world. I don’t mind the “don’t re-invent the wheel” idea, in fact it’s good. The problem comes in claiming it as a brand new, original idea.

My error. I will claim distraction, I had a plumber in fixing a faulty shut-off valve for the washer feed. Post edited.

No worries at all :)

The problem comes in claiming it as a brand new, original idea.

Can you provide evidence of where Agile methodologies authors claimed that testing was a new and original idea? Because this is where Steffen’s incorrect assumption is.

For reference here is the official Agile manifesto: https://agilemanifesto.org

It clearly states BETTER ways of developing software in response to the previous software development model. NOT new and original ideas.

Here are the 12 principles of Agile methodologies: https://agilemanifesto.org/principles.html

Again no claims of new and original.

Here is Test Driven Development manifesto: https://tddmanifesto.com

Again no claims of new or original. However the name put the emphasis on writing code tests before writing features, in order to ensure validation at the smallest unit of work (this indeed is original to TDD, as previous methodologies used to test after and at solution level, but again there is no claim of new or originality)

This is the definition of BDD: behavior-driven development (BDD) is a software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. More info here: https://www.agilealliance.org/glossary/bdd/

For the point where I have mentioned that testing is so important to Agile methodologies, by reading all their manifestos it’s clear that all the Agile methodologies are based on “constant verification” and direct collaboration of all parties, which obviously includes testing at all levels (again read my article to understand what this means in practical terms) and user feedback. Before Agile methodologies both these two activities were done in specific (and late) phases of a project and generally not by the developers.

Hope this helps

Testing became part of the developer process and not anymore an “added” process.

I can’t help but think that the problem here is what does one mean by the word “test”?

When developing software, there are numerous different forms of testing that take place, some during the development itself, some by the programmers, and some that are best never don’t by the programmers.

You test functions. You test functions with invalid input. You test functions grouped into a unit. You test…(record scratch noise)…the finished program behaves as documented.

Ermmm please let’s avoid these unfounded and personal opinions.

Every so often the world goes “whoo!” for the new greatest thing…until the next one comes along. Whether it is cars, programming languages, games consoles, or development methodologies, it’s the same story.

Expect all that you currently know to be swept away and replaced with exactly the same thing but with A.I.!

well… a constant refactor out of customer complaining that we did not implement what they wanted.

Is this a weakness of agile in that the goalposts can keep moving, or just a manager that failed to pin the customer down on exactly what they wanted and fully document that prior to writing any code?

that Product wasn’t as good as they should have been, but it was too late for the project.

I’ve just read several documents about agile (such as https://www.cprime.com/resources/what-is-agile-what-is-scrum/) and it seems to me to be a sensible way of creating software wrapped up in many buzzwords.
Take, for example:

• Testing is a part of development
• There should be one, and only one, person who is the ultimate reference for how something is supposed to happen (and this backed up by the written project specification)
• Be flexible to allow the software to be able to change according to requirements (but not so flexible that the entire project is a write-off because nobody could agree on anything)
• Maximise productivity (which goes hand in hand with…)
• Have somebody to act as a liaison between the programmers and management so the pen pushers can get regular updates and the coders don’t have to waste an hour a day in pointless meetings that a manager calls in order to feel a part of the team even though said manager’s level of technical competence maxes out at “are you sure it is plugged in?”
• Write the technical documentation at the same time as the code it describes, not afterwards.
• Create tasks, let the programmers work out between themselves who does what. A task, when assigned, is the sole responsibility of that person (so if somebody is writing, say, a fancy fixed point maths library, all everybody else knows is the documented API for how to call it; failure to adhere to this risks collusion and assumptions that could blow up spectacularly if the underlying library is changed (say, to use floating point because newer hardware has it))
• Only twiddle the global headers if you are in possession of the pink dinosaur.

None of this is “agile”, it’s simply a sensible way for team-developed software to be created. It’s not the free-for-all that homebrew software is, there must be clear roles, clear goals, and a consistent sequence of events to get from empty editor screen to finished product.

then let it be tested by others in whatever extent they can.

Yes, once a programmer has tested their own code (as a normal part of creating it), it is important to let others test things.

I miss mom. She was great at testing things. A dialogue says “enter a number”, she’d type “aardvark”. Once got a silly game site to crash with a PHP error. It invited her to enter a number less than ten. It couldn’t handle a zero. ;)
It’s as if she took a question and deliberately thought of the most obtuse thing possible in order to test that it coped sensibly with the input.

[extra special mom bonus: she enjoyed performing this test with biological processing units, some of which would glitch in interesting ways]

And this is why the final testing should never be done by the programmer. They might not think to do X, they might not bother if they did think of it because that can’t happen ¹, it’ll never happen ², that’s just not an option ³.

¹ Mom’s ghost would like a word…

² So I have this bit of code where a value is either true or false. A bug elsewhere screwed up the stack meaning the function was errantly entered with an input that was neither true nor false. It coped badly as I’d assumed (given its only ever called with true and false) that these were the things to test for; so now the test is for true and not-true, even though the other bug was fixed and the event can’t happen like that again, there’s still the possibility that I might forget in several years time and give it invalid input ⁴, so now it’ll not blow up…

³ See the above footnote.

⁴ Language issues: if the language in use supports true boolean parameters, then only true and false are valid inputs. I don’t use such a language…

Is this a weakness of agile in that the goalposts can keep moving, or just a manager that failed to pin the customer down on exactly what they wanted and fully document that prior to writing any code?

In our particular case it was a weak communication of the Product/sales department with the customer. I always had the impression they were making those requirements up without consulting the actual customer. So it would have gone bad regardless the process, however Agile did help to correct the trajectory even in such an unfortunate case.

I’ve just read several documents about agile (such as https://www.cprime.com/resources/what-is-agile-what-is-scrum/) and it seems to me to be a sensible way of creating software wrapped up in many buzzwords.

Read the manifesto instead, you’ll see quickly what I meant before. Agile, over the years have been re-interpreted many times and with all sorts of outcomes included a “masked water fall” which ain’t agile at all.

IMHO, the problem is in the categories of developers (citing Gavin’s reference to categorization here), some developer prefer to work in a process where as many rules are well defined, while others prefer to work in an process with as a minimal amount of defined rules as possible. And, obviously there is everything in. between. This normally tend to generate the situation where you can read 10 websites that tries to teach you agile and each and everyone of them has different sets of rules.

Obviously, rules can express also buzz words, as I have mentioned before, the 2024 Cyber Security words dictionary is composed by 116 pages full of acronyms and buzz words to describe products that do basically ALL the same thing, but that trying to define them as different products helps selling them more ’cause a customer may buy a bunch of them basically (forgive this absolutely simplistic explanation, but I wanted to be as short as possible on this reference).

None of this is “agile”, it’s simply a sensible way for team-developed software to be created.

Why not? I mean, if a rule allow your team to increase their agility then yes it’s agile. The difference with the Agile manifesto is that it was voluntarily written as short as possible to avoid re-incarnating previous methodologies that were considered the source of certain issues.

Now if you just don’t want to call something with the name accepted by many and just say it’s a set of sensible rules, remember the manifesto says this as well, it’s just a set of good practices to improve the agility of software development, hence the term agile. There isn’t a need for claiming originality or new ideas.

Yes, once a programmer has tested their own code (as a normal part of creating it), it is important to let others test things.

You are missing the point here. It’s not just about who tests what, but it’s about doing it as a single team, so, YES developers should be ALSO part of the more formal and “external” testing phases, not just unit testing.

This is even more prominent in DevOps practice and now in DevSecOps practices, where even the Cyber Security team is combine din a single team with engineering devs and QA (quality of Assurance). The reason for this is to reduce “silos” as much as possible and improve communication as much as possible.

Why communication is so vital? For the same reason we are having this discussion ;) – Different assumptions can make people disagree even if they are trying to say the same thing. And it is real.

This, for example, it’s also why that thing of “we need to write readable code” is a “utopia” . As a practical example, a software engineer (let’s call it Mary) used to work on controllers and low-level development is perfectly happy and able to read C or C++ that uses bitwise operations and complex pointers’ math, however Mary never used OOP, so for Mary code that modifies bits can be considered readable. Bob in the other hand has always used OOP and very high level concepts and find it difficult to understand bitwise operations or pointers math. They both use C or C++ but they will have difficulty to read each other code.

So, is Bob code wrong? Not if the compiler builds exactly what Bob mean to build and the same is true for Mary’s code. Their code, however, will become “readable” for both only when both will share the same background culture and not just the understanding of some applied forms of their shared language.

The same can happen between Americans and British (and believe me I am a “victim between two fires” here!!! ahaha XD ).

And with this I hope I have explained my point correctly, but I am sure I haven’t, because… well because of the above reality ;)

All very interesting, but no amount of testing is going to get RISC OS or it’s applications through this latest EU nonsense.

All very interesting, but no amount of testing is going to get RISC OS or it’s applications through this latest EU nonsense

Hello David,

I’m not sure if you’ve been keeping up with the initial discussions, but I’ll provide a brief recap:

Understanding the Impact of the EU CRA:

The EU Cyber Security Regulation Act (CRA) primarily impacts software that is paid for or funded (such as through the ROD model and bounties). Here’s how it breaks down:

• Open Source Free RISC OS and Applications: These remain unaffected. The EU CRA does not impact free open-source RISC OS and associated apps.
• Commercial, paid support and Funded Projects: Entities like ePic, DDE, ROD Founded projects, bounties and others selling goods/services or software based on RISC OS to EU customers will likely need to comply with the CRA. This means, at a minimum, adhering to procedural requirements and hoping no issues are reported. Alternatively, they might consider ceasing sales to the EU.

‘Wish List’ for Enhanced Security and Compliance:

While the above are the current feasible actions, here’s what would help (but most likely won’t be feasible) to further enhance RISC OS in response to the CRA:

Collaborative Development: Encourage a unified effort to:¹

• Develop a secure user-space emulator to run old apps in isolation, akin to porting and modifying RPCEmu to run one app per instance on RISC OS itself.
• Enhance the hypervisor approach to allow apps to run isolated from the OS, reducing the risk of apps and their libs becoming attack vectors.
• Utilize or develop solutions like my UltimaVM, which runs apps in a controlled and compartmentalized manner. However, this would require significant porting/rewriting of old apps and is likely infeasible for legacy software.

App Isolation: Regardless of the approach, isolating apps from each other and the kernel is crucial. This isn’t natively feasible for RISC OS without relying on emulation or a hypervisor, but it’s essential to mitigate the risks associated with vulnerabilities in the system.

Permission Model: RISC OS’s lack of a robust permission model is a significant hurdle. We need a way to define and enforce what apps can and cannot do, including their access to files, networking and writing capabilities. While I’ve incorporated this into my VM, again the VM it’s most likely not a solution for older applications.

Seeking Community Input:
This is an ongoing discussion, and I’m eager to hear more ideas and perspectives. If you have suggestions or strategies to navigate these challenges, please contribute to the conversation.

¹ Keep in mind that this level of effort will require time and will present bugs that need addressing, so it won’t be completed “overnight”