www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cyber Resilience Act

reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
Hi!

I want to quickly bring up a topic that is certain to annoy 
everybody. I'm sure of it.

The European Union has passed the Cyber Resilience Act (CRA) a 
while ago, which imposes regulatory requirements on software 
distributed in the European Union. The implementation is in 
phases and right now, only the mandatory reporting of exploitable 
vulnerabilities in effect since 11. September. But starting 11. 
December 2027, software distributed in the EU may need to undergo 
a certification process to ensure that the product fulfills 
certain minimum security standards.

The whole thing is described in detail here: 
https://www.cyberresilienceact.eu/index.html

The short version, as I (not a lawyer!) understand it, is as 
follows:

Software falls under the certification requirement as soon as 
certain features are present. For example, the mere ability to 
communicate over a network triggers the requirement. So, if your 
software contacts a server to check if a new version is 
available, you've overstepped that boundary already. There are 
other criteria, and they split software into four broad 
categories:

- Critical: secure hardware with "digital elements" like smart 
cards, card readers etc.
- Important, class 2: firewalls, hypervisors, tamper-resistant 
microcontrollers/microprocessors
- Important, class 1: operating systems, browsers, identity and 
access management, password managers, malware scanners, network 
management and a couple more categories
- Default: most business software, games, etc...

The default category of software, which is the broadest category, 
is allowed to undergo a self-certification process. The other 
categories must be certified by an external named body.

Certification is only possible with a bunch of documentation 
describing how security is achieved and maintained in the 
product. This stuff needs to be written, even when 
self-certifying. There are some requirements for what that 
documentation has to cover. There are both technical and 
non-technical (process) parts.

Open source software is not fully exempt, although the 
requirements are very different and, arguably, much more lax. I 
think that for most serious open source projects, this should 
come down to providing a solid reporting and handling process for 
security vulnerabilities. Many other requirements shift to 
whatever commercial entity makes use of open source components.

It seems really, really hard to avoid the CRA entirely while 
retaining to the right to distribute software in EU member 
states. The implications of this, as I understand them, are 
twofold:

- The D Language Foundation may be potentially subject to the 
rules for open source stewardship. This should be checked before 
the deadline, probably by persons that are more knowledgeable 
than I am right now.

- Commercially distributed software that uses D is very likely to 
fall under the certification requirement. Those developers will 
have to document how they use D and its libraries to make a 
secure product.

Are there already plans in place to evaluate how the D Language 
Foundation is affected and how to adjust? I suspect that this 
will require a whole lot of reading and a few minor policy 
changes at most.

Finally, and probably more controversially, is there any interest 
in building documentation that helps users of D go through 
certification? This could be in the form of a brief manual that 
outlines how D code can be written and compiled to avoid certain 
classes of security vulnerabilities (GC: no use after free, 
bounds checking: no buffer overflows, etc.) as well as outlining 
how e.g. the networking features in Phobos are implemented 
securely. Doing this collaboratively in the open may help lessen 
the load for each individual team out there a little.

Gregor

PS: please keep this discussion focused. Complaining about things 
like "EU overregulation" is not a productive contribution. If you 
feel the urge to vent, please start a separate thread.
Sep 16
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
wrote:

 [Snip]


I'm going to be pretty blunt on this but we just went through 
something similar with LLM usage and the EU.

The DLF is wholly located in the US and thus is subject solely to 
the jurisdiction of the US. The EU can do exactly nothing to the 
DLF from a legal standpoint without severing their internet 
connections with the US (and anywhere else outside EU borders).

If EU persons download and use D, then they are entirely 
responsible for managing their compliance with EU law. 
Furthermore, there is nothing the DLF can do legally to help them 
as DLF has no legal presence in the EU and thus no access to 
lawyers who could help ensure compliance. This was also requested 
during the LLM debate and then, as now, the DLF concluded that it 
had no ability to make such a legal proclamation.

There are no plans to adjust anything. Nor would we be able to 
enforce any such rules on package maintainers.

All D users in the EU are strongly recommended to seek local 
counsel in this and other matters. The DLF cannot provide any 
legal guidance.
Sep 16
next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 16 September 2026 at 12:32:30 UTC, Adam Wilson 
wrote:

 All D users in the EU are strongly recommended to seek local 
 counsel in this and other matters. The DLF cannot provide any 
 legal guidance.


Well at least the code managed by DLF should comply as much as 
possible with these regulations, even if org itself doesn't 
provide any legal counsel, guarantees, or certification of 
compliance with these rules, right?

Otherwise what would be use of D in Europe? Companies there would 
just ignore it, and hence D would lose a sizeable market which it 
can be adopted.
Sep 16
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 16 September 2026 at 19:49:42 UTC, Alexandru 
Ermicioi wrote:

 On Wednesday, 16 September 2026 at 12:32:30 UTC, Adam Wilson 
 wrote:

 All D users in the EU are strongly recommended to seek local 
 counsel in this and other matters. The DLF cannot provide any 
 legal guidance.


 Well at least the code managed by DLF should comply as much as 
 possible with these regulations, even if org itself doesn't 
 provide any legal counsel, guarantees, or certification of 
 compliance with these rules, right?


No, obeying the nist's push for "borrow checkers will fix 
software" made  live; hows that feature going?

Cookie banners didnt fix anything; *maybe* you could care if the 
people running the world didn't think fax machines were new and 
knew how to print a pdf, they dont tho; it will be irrelevant 
dribble.
Sep 16
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 16 September 2026 at 21:41:54 UTC, monkyyy wrote:

 On Wednesday, 16 September 2026 at 19:49:42 UTC, Alexandru 
 Ermicioi wrote:

 On Wednesday, 16 September 2026 at 12:32:30 UTC, Adam Wilson 
 wrote:

 All D users in the EU are strongly recommended to seek local 
 counsel in this and other matters. The DLF cannot provide any 
 legal guidance.


 Well at least the code managed by DLF should comply as much as 
 possible with these regulations, even if org itself doesn't 
 provide any legal counsel, guarantees, or certification of 
 compliance with these rules, right?


 No, obeying the nist's push for "borrow checkers will fix 
 software" made  live; hows that feature going?


It was a genuine attempt at improving the state, albeit a failed 
one it seems (just like dip1000). Now D seems to move to a better 
borrow checker it seems.



 Cookie banners didnt fix anything;


It is a change in good direction, would be nice if such laws will 
apply to other things like tvs as well, otherwise now you need to 
read that a turned off toggle in tv for enabling adds is actually 
disabling adss...


 *maybe* you could care if the people running the world didn't 
 think fax machines were new and knew how to print a pdf, they 
 dont tho; it will be irrelevant dribble.


Indeed it might happen that bad laws can be made, we just need to 
push back, when we know it is a bad law, ignoring it will just be 
detrimental.

Anyway, it would be nice in best effort non-binding (legally) 
approach to follow the resiliency act where it genuinely suggests 
good things.
Sep 16
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 16 September 2026 at 19:49:42 UTC, Alexandru 
Ermicioi wrote:

 Well at least the code managed by DLF should comply as much as 
 possible with these regulations, even if org itself doesn't 
 provide any legal counsel, guarantees, or certification of 
 compliance with these rules, right?


I don't see how we could. The first invasive or API change to 
DMD/DRT/Phobos2 will be automatically vetoed.

The problem is that the moment that we say "We will try to 
comply" you create a binding legal declaration that you are going 
to comply with the regs and can be sued if we make a mistake.

Doing something half-way would be the worst of both worlds. All 
the legal liability, none of the rigorous compliance that would 
actually shield us from liability.
Sep 16
parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 16 September 2026 at 23:50:31 UTC, Adam Wilson 
wrote:

 ...
 Doing something half-way would be the worst of both worlds. All 
 the legal liability, none of the rigorous compliance that would 
 actually shield us from liability.


There are also non-binding statements, like stating that it will 
be best-effort approach though it will not guarantee full 
compliance (also explicitly say it is nonbinding perhaps).
At minimum would be good to have some guarantees/confirmation, 
that changes making dlf owned software compliant, wouldn't be 
blocked unless there is a reasonable cause.

The point I'm trying to make is, if possible it should be 
compliant so the work necessary to certify it by third party in 
europe is as minimal as possible.
Sep 16
prev sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 16 September 2026 at 12:32:30 UTC, Adam Wilson 
wrote:

 On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
 wrote:

 [Snip]


 I'm going to be pretty blunt on this but we just went through 
 something similar with LLM usage and the EU.

 The DLF is wholly located in the US and thus is subject solely 
 to the jurisdiction of the US. The EU can do exactly nothing to 
 the DLF from a legal standpoint without severing their internet 
 connections with the US (and anywhere else outside EU borders).

 If EU persons download and use D, then they are entirely 
 responsible for managing their compliance with EU law. 
 Furthermore, there is nothing the DLF can do legally to help 
 them as DLF has no legal presence in the EU and thus no access 
 to lawyers who could help ensure compliance. This was also 
 requested during the LLM debate and then, as now, the DLF 
 concluded that it had no ability to make such a legal 
 proclamation.

 There are no plans to adjust anything. Nor would we be able to 
 enforce any such rules on package maintainers.

 All D users in the EU are strongly recommended to seek local 
 counsel in this and other matters. The DLF cannot provide any 
 legal guidance.


Adam, I think that this is not comparable to the LLM situation.

As I understand it, the DLF seems to fall into the category of an 
Open Source Stewards and thus has requirements to fulfill under 
the CRA. This status exempts the DLF from financial penalties and 
any formal certification requirements, but makes it 
(theoretically) subject to other enforcements, including barring 
the software under its stewardship from commercial use in the EU.

If it were to come to that, companies like Auburn Sound, Funkwerk 
or Weka.io would no longer be able to sell products containing D 
code in the EU. Granted, this would be an extreme measure and the 
DLF would have to ignore some sternly worded official letters 
before it comes to that.

The DLF can meet the CRA requirements without formally declaring 
that the measures are for compliance. For strictly open source 
projects, the CRA is about what happens in practice. That seems 
to be a safe route and as I understand it, that part means 
ensuring development best practices:

- Have development processes in place that reduce the risk that 
code changes lead to exploitable software vulnerabilities.
- Have a vulnerability reporting and handling process that deals 
with actual vulnerabilities in a reasonable time

As I see it, the action items for the DLF are, derived from CRA 
Article 24 and Article 14(1), 14(3) and 14(8):

- Lightly document the the exisiting day to day development 
routine (essentially say that code reviews and automated tests 
etc. are quality bars that need to be passed, the tests need to 
stay up to date, etc.)
- Write out a (loose) policy for handling security 
vulnerabilities in DMD and Phobos (GDC should fall under the 
FSF's stewardship, not sure where LDC2 sits). This should 
probably include publishing a list of (known) security 
vulnerabilities/fixes so that developers using D can address 
those in their products.
- Establish a policy to report to ENISA any exploited 
vulnerabilities in DLF run infrastructure. To me, it seems as if 
this is just like the upcoming CISA reporting requirements.
- Actually try to follow these processes in the future.

Most of this is a good thing anyway, CRA compliance or not.

Gregor
Sep 17
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 17 September 2026 at 09:15:59 UTC, Gregor Mückl 
wrote:

 Adam, I think that this is not comparable to the LLM situation.

 As I understand it, the DLF seems to fall into the category of 
 an Open Source Stewards and thus has requirements to fulfill 
 under the CRA. This status exempts the DLF from financial 
 penalties and any formal certification requirements, but makes 
 it (theoretically) subject to other enforcements, including 
 barring the software under its stewardship from commercial use 
 in the EU.

 If it were to come to that, companies like Auburn Sound, 
 Funkwerk or Weka.io would no longer be able to sell products 
 containing D code in the EU. Granted, this would be an extreme 
 measure and the DLF would have to ignore some sternly worded 
 official letters before it comes to that.

 The DLF can meet the CRA requirements without formally 
 declaring that the measures are for compliance. For strictly 
 open source projects, the CRA is about what happens in 
 practice. That seems to be a safe route and as I understand it, 
 that part means ensuring development best practices:

 - Have development processes in place that reduce the risk that 
 code changes lead to exploitable software vulnerabilities.
 - Have a vulnerability reporting and handling process that 
 deals with actual vulnerabilities in a reasonable time

 As I see it, the action items for the DLF are, derived from CRA 
 Article 24 and Article 14(1), 14(3) and 14(8):

 - Lightly document the the exisiting day to day development 
 routine (essentially say that code reviews and automated tests 
 etc. are quality bars that need to be passed, the tests need to 
 stay up to date, etc.)
 - Write out a (loose) policy for handling security 
 vulnerabilities in DMD and Phobos (GDC should fall under the 
 FSF's stewardship, not sure where LDC2 sits). This should 
 probably include publishing a list of (known) security 
 vulnerabilities/fixes so that developers using D can address 
 those in their products.
 - Establish a policy to report to ENISA any exploited 
 vulnerabilities in DLF run infrastructure. To me, it seems as 
 if this is just like the upcoming CISA reporting requirements.
 - Actually try to follow these processes in the future.


All of this is a very complex way of saying that DLF will have to 
hire EU counsel to write these policies and provide ongoing 
oversight of code changes and responses to security incidents to 
ensure continuing compliance.

DLF nor it's individual contributors have the financial or legal 
capability to do this on their own. The only way this will happen 
is that such counsel and compliance will have to be funded by 
commercial/monied users of D within the EU.

This is why the only realistic path is for individual EU based 
corps to self-certify their usage of D.

The reason that I said that this is similar to LLM situation is 
that in both cases, people are/were asking the DLF and it's 
contributors to shoulder the burden of compliance so that they 
didn't have to.

If you are located in the EU you already need local counsel to 
ensure compliance.
Sep 19
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Saturday, 19 September 2026 at 18:01:44 UTC, Adam Wilson wrote:

 All of this is a very complex way of saying that DLF will have 
 to hire EU counsel to write these policies and provide ongoing 
 oversight of code changes and responses to security incidents 
 to ensure continuing compliance.


No, it's actually not. Just make sure to follow proper best 
practices regarding secure software development, CRA or not. As 
long as you do that, you're in the clear and you reduce your 
users' compliance workload implicitly.
Sep 19
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Saturday, 19 September 2026 at 18:19:41 UTC, Gregor Mückl 
wrote:

 On Saturday, 19 September 2026 at 18:01:44 UTC, Adam Wilson 
 wrote:

 All of this is a very complex way of saying that DLF will have 
 to hire EU counsel to write these policies and provide ongoing 
 oversight of code changes and responses to security incidents 
 to ensure continuing compliance.


 No, it's actually not. Just make sure to follow proper best 
 practices regarding secure software development, CRA or not. As 
 long as you do that, you're in the clear and you reduce your 
 users' compliance workload implicitly.


I would point out that this is entirely your personal opinion. No 
lawyer I've talked would ever say "Yea man, just wing it bro", 
which is effectively what you're saying we should do. If a policy 
is required by statute than the policy must be written, enforced, 
and on-going compliance oversight maintained either by counsel or 
independent audit.

The DLF has neither the money nor the human-time capacity to 
"reduce users' compliance workload implicitly." Compliance with 
local statutes has always been the sole responsibility of the 
end-user of any software.

The DLF is not and cannot be responsible for ensuring compliance 
with local security statutes for exactly the same reason as the 
DLF is not and cannot be responsible for ensuring compliance with 
local copyright statutes. The logic is no different, even if the 
text of the law is.

The community will continue to fix bugs, including security 
vulnerabilities, as fixes are offered and such fixes meet our 
engineering standards. But we cannot compel any human to do such 
work without compensation as that would be slavery and is highly 
illegal.

If you want to help the DLF comply with your local statutes then 
you or your employer will have to pay the bill for your time. The 
DLF simply does not have the capability to make any compliance 
guarantees of any kind for any reason, be it Copyright or 
Security laws.
Sep 19
prev sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Saturday, 19 September 2026 at 18:19:41 UTC, Gregor Mückl 
wrote:

 On Saturday, 19 September 2026 at 18:01:44 UTC, Adam Wilson 
 wrote:

 All of this is a very complex way of saying that DLF will have 
 to hire EU counsel to write these policies and provide ongoing 
 oversight of code changes and responses to security incidents 
 to ensure continuing compliance.


 No, it's actually not. Just make sure to follow proper best 
 practices regarding secure software development, CRA or not. As 
 long as you do that, you're in the clear and you reduce your 
 users' compliance workload implicitly.


I personally can't think how this will be enforceable in a way 
that is not just "let's check the 7-8 mega corps and ignore the 
rest."
That's how this reads to me. Also, it's hard to take the EU 
seriously when they are the ones that gave us attached bottle 
caps. That are not really on every bottle (probably a reason for 
it, but what's the point).
Sep 20
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Off the top of my head it's unsafe serialization practices (how 
popular are they?) and the -release compiler switch.
Sep 16
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 16 September 2026 at 15:50:22 UTC, Kagamin wrote:

 Off the top of my head it's unsafe serialization practices (how 
 popular are they?) and the -release compiler switch.


It's a bit more than that. Looking at  MITRE's CWE Top 25 as an 
arbitrary reference [1], I a couple of vulnerability classes that 
can be produced in carelessly written D code:

- Out-of-bounds Write
- Improper Limitation of a Pathname to a Restricted Directory 
('Path Traversal')
- Use After Free
- Out-of-bounds Read
- Improper Neutralization of Special Elements used in an OS 
Command ('OS Command Injection')
- Buffer Copy without Checking Size of Input ('Classic Buffer 
Overflow')
- NULL Pointer Dereference
- Stack-based Buffer Overflow
- Heap-based Buffer Overflow
- Improper Neutralization of Special Elements used in a Command 
('Command Injection')

Gregor

[1] https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
Sep 17
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/17/2026 2:35 AM, Gregor Mückl wrote:

 It's a bit more than that. Looking at  MITRE's CWE Top 25 as an arbitrary 
 reference [1], I a couple of vulnerability classes that can be produced in 
 carelessly written D code:
 
 - Out-of-bounds Write
 - Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal')
 - Use After Free
 - Out-of-bounds Read
 - Improper Neutralization of Special Elements used in an OS Command ('OS
Command 
 Injection')
 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
 - NULL Pointer Dereference
 - Stack-based Buffer Overflow
 - Heap-based Buffer Overflow
 - Improper Neutralization of Special Elements used in a Command ('Command 
 Injection')
 
 Gregor
 
 [1] https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
 


Most of those are not allowed in code tagged with  safe.
Sep 20
prev sibling next sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
wrote:

 Hi!

 I want to quickly bring up a topic that is certain to annoy 
 everybody. I'm sure of it.
 [...]


Thanks, I wanted to know how is this enforced. I'll save other 
people a few searches:

(Gemini verbatim begins)

---

Enforcement of the EU **Cyber Resilience Act (CRA)** is **not 
centralised** under a single European Union body. Instead, 
enforcement is managed decentrally by individual EU member states.


* **Market Surveillance Authorities (MSAs):** Each member state 
designates national market surveillance authorities to enforce 
compliance, inspect products with digital elements, and impose 
penalties or product recalls for non-compliance.
* **Notifying Authorities:** Member states designate specific 
bodies to assess and accredit conformity assessment 
organizations. For example, in France, the ANSSI acts as the 
notifying authority.
* **CSIRTs & ENISA:** Computer Security Incident Response Teams 
coordinate locally regarding incident reports, while the 
**European Union Agency for Cybersecurity (ENISA)** operates the 
centralized Single Reporting Platform (SRP) for vulnerability 
notifications, though ENISA itself holds no direct enforcement or 
penalty powers.

---

(Gemini verbatim ends)

So basically the RCA is made as a tool to taxes the tech-giants. 
It is a bit obscure how and if the sword will hit you. that 
depends on how each particular EU member decides to deal wi the 
RCA.

The risks are


 Non-compliance with the essential requirements or manufacturer 
 obligations can attract fines of up to €15 million or 2.5% of 
 total worldwide annual turnover, whichever is higher. Lower 
 ceilings apply to other infringements and to supplying 
 incorrect information.


So in a nutshell. Unless you are a tech giant you can ignore the 
RCA.
Sep 16
next sibling parent reply Arafel <er.krali gmail.com> writes:
On 9/17/26 08:52, user1234 wrote:

 
 So basically the RCA is made as a tool to taxes the tech-giants. It is a 
 bit obscure how and if the sword will hit you. that depends on how each 
 particular EU member decides to deal wi the RCA.
 
 The risks are
 

 Non-compliance with the essential requirements or manufacturer 
 obligations can attract fines of up to €15 million or 2.5% of total 
 worldwide annual turnover, whichever is higher. Lower ceilings apply 
 to other infringements and to supplying incorrect information.


 
 So in a nutshell. Unless you are a tech giant you can ignore the RCA.


In order to reinforce this point and to focus the discussion, I would 
like to point out that non-profit open source is fully exempted [1]:


 The CRA recognises that, to foster the development and deployment of free and
open-source software, special attention should be paid to the nature of the
different development models of software distributed and developed under free
and open-source software licences.  
 
 This is why only **free and open-source software** that is made available on
the market, and therefore supplied for distribution or use in the course of a
commercial activity, falls in scope of the Cyber Resilience Act. Notably, the
provision of products with digital elements qualifying as free and open-source
software that are not monetised by their manufacturers should not be considered
to be a commercial activity. Additionally, the CRA does not apply to developers
who contribute with source code to free and open-source software that are not
under their responsibility.


Then it goes on to include some nuances for those cases where somebody 
provides paid support for otherwise free and open source software ("open 
source software stewards").

I know I'll be in the minority or even alone here, but, all in all, and 
without having read the full details, I do think that it is a good step 
in the right direction. Wild deregulation and no responsibility 
whatsoever for bugs and vulnerabilities is not any good for anybody in 
the long term.

[1]: https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
Sep 17
parent monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 17 September 2026 at 08:54:06 UTC, Arafel wrote:

  Wild deregulation and no responsibility whatsoever for bugs 
 and vulnerabilities is not any good for anybody in the long 
 term.


Anarcho-tyranny follows when the cops are cowards.

*ANY* law that targets unfunded opensource devs with any 
requirement but does nothing for the daily credit card database 
hack is shit. The ai companies are disobeying laws already on the 
books like hacking into servers.

No, dlang is not part of the security nightmare, no amount of 
fiddling with annotating dlang functions headers, or dlang 
compiler features or or or or will have 1 iota of effect on if 
your social security number gets leaked because they gave that to 
the lowest bidder for government paperwork that you were forced 
to sign and probably didn't need it.

no no no no no; theres a handful are retarded design decisions 
about the world that cause almost all of the problems. Suggesting 
effort or responsibility elsewhere is just like the oil companies 
funding recycling ads.
Sep 17
prev sibling next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 17 September 2026 at 06:52:02 UTC, user1234 wrote:

 On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
 wrote:

 Hi!

 I want to quickly bring up a topic that is certain to annoy 
 everybody. I'm sure of it.
 [...]


 Thanks, I wanted to know how is this enforced. I'll save other 
 people a few searches:

 [...]


This summary does not seem to cover non-financial repercussions. 
Vulnerable software may be barred from distribution in the EU, 
independently of any financial penalties.

Also, dismissing this regulation as taxation of US tech giants is 
simply false. The enforcement structure is similar to that of the 
GDPR. And in reality, GDPR enforcement, including fines, is used 
more often against EU companies than foreign companies. It just 
doesn't get reported because the incidents and penalties are not 
as spectacular.

Gregor
Sep 17
prev sibling parent user1234 <user1234 12.de> writes:
On Thursday, 17 September 2026 at 06:52:02 UTC, user1234 wrote:

 [...]
 So in a nutshell. Unless you are a tech giant you can ignore 
 the RCA.


Sorry for being a bit provo but the RCA is a bit a polymorphic 
law (a template). How it is applied is a monomorphization. The 
original poster has well said that


 please keep this discussion focused. Complaining about things 
 like "EU overregulation" is not a productive contribution. If 
 you feel the urge to vent, please start a separate thread


so I'll stop there.
Sep 17
prev sibling next sibling parent reply Mindy Bate (0xEAB) <desisma heidel.beer> writes:
On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
wrote:

 The European Union has passed the Cyber Resilience Act (CRA) a 
 while ago


As far as the advice that has been put forward to me goes, DLF is 
unaffected as it does not vendor commercial software.
Sep 17
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 18 September 2026 at 01:40:18 UTC, Mindy Bate (0xEAB) 
wrote:

 As far as the advice that has been put forward to me goes, DLF 
 is unaffected as it does not vendor commercial software.


Where did you get that advice from? Article 24 of the Cyber 
Resilience Act specifically covers open source software and 
defines the role of open source steward. The reason you give 
seems incorrect to me.
Sep 17
parent reply Mindy Batek (0xEAB) <desisma heidel.beer> writes:
On Friday, 18 September 2026 at 05:32:05 UTC, Gregor Mückl wrote:

 Article 24 of the Cyber Resilience Act specifically covers open 
 source software and defines the role of open source steward.


I’m not a lawyer but I’d recommend you to take a glimpse at the 
term’s definition in 3.14.
Sep 18
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 18 September 2026 at 21:44:49 UTC, Mindy Batek (0xEAB) 
wrote:

 On Friday, 18 September 2026 at 05:32:05 UTC, Gregor Mückl 
 wrote:

 Article 24 of the Cyber Resilience Act specifically covers 
 open source software and defines the role of open source 
 steward.


 I’m not a lawyer but I’d recommend you to take a glimpse at the 
 term’s definition in 3.14.


I don't understand what you're getting at with this. I assume you 
mean this passage:

```
‘open-source software steward’ means a legal person, other than a 
manufacturer, that has the purpose or objective of systematically 
providing support on a sustained basis for the development of 
specific products with digital elements, qualifying as free and 
open-source software and intended for commercial activities, and 
that ensures the viability of those products;
```

How does this apply to what I wrote above?
Sep 19
parent reply Mindy Batek (0xEAB) <desisma heidel.beer> writes:
On Saturday, 19 September 2026 at 18:25:00 UTC, Gregor Mückl 
wrote:

 I don't understand what you're getting at with this. I assume 
 you mean this passage:

 ```
 ‘open-source software steward’ means a legal person, other than 
 a manufacturer, that has the purpose or objective of 
 systematically providing support on a sustained basis for the 
 development of specific products with digital elements, 
 qualifying as free and open-source software and intended for 
 commercial activities, and that ensures the viability of those 
 products;
 ```

 How does this apply to what I wrote above?


Article 3 defines the terms used throughout the document. Any use 
of these terms later on is based on these definitions; for 
example article 24 specifies the obligations of an entity as 
defined in 3.14.
Sep 25
parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 25 September 2026 at 17:45:25 UTC, Mindy Batek (0xEAB) 
wrote:

 On Saturday, 19 September 2026 at 18:25:00 UTC, Gregor Mückl 
 wrote:

 [...]


 Article 3 defines the terms used throughout the document. Any 
 use of these terms later on is based on these definitions; for 
 example article 24 specifies the obligations of an entity as 
 defined in 3.14.


careful, your sounding like a lawyer, actually reading laws
thats illegal to know how to law works
Sep 25
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2026 2:15 AM, Gregor Mückl wrote:

 This could be in 
 the form of a brief manual that outlines how D code can be written and
compiled 
 to avoid certain classes of security vulnerabilities (GC: no use after free, 
 bounds checking: no buffer overflows, etc.)


Writing an article "Safe and Secure Coding with D" would be a nice project! Any 
takers?
Sep 20