The European Cyber Resilience Act
The security of digital products has become a topic of regulation in recent years. Currently, the European Union is moving forward with another new law, which, if it comes into effect in a form close to the current draft, will affect software developers worldwide. This new proposal, called the "Cyber Resilience Act" (CRA), brings mandatory security requirements on all digital products, both software and hardware, that are available in Europe. While it aims at a worthy goal, the proposal is causing a stir among open-source communities.
There is a reason why the open-source world has concerns: the legislation indirectly defines who is responsible for the security of open source and who should pay to improve the current state. In addition, it puts the responsibility on individual developers and foundations hosting open-source projects instead of the manufacturers of goods embedding the software. It could have important consequences for open source across the globe.
The original proposal of the CRA (the main text
and the annexes)
brings several requirements (enumerated in Annex I) for "products on
the market
" (more on definitions a little later). Most requirements
are generally accepted best-practices, such as a secure default
configuration, providing security updates, protection from unauthorized
access, and releases free of known vulnerabilities; others could be
considered somewhat vague
like "(g) minimise their own negative impact on the availability of
services provided by other devices or networks
".
Each product (which means every release for software) would need to provide
"an
assessment of the cybersecurity risks
" along with the release-related
documentation (listed in Annex II).
The security assessment covers the software itself and all its
dependencies; the way to perform the assessment could fall under one
of three categories,
from self-assessment to the involvement of a third party.
Self-assessment is the default. However, the regulation requires a
stricter approach
when the product's "core function
" falls into the category of a
"critical product with digital elements
" (listed in Annex III),
which is further
divided into
Class I (less critical) and Class II (more critical). Depending
on their class, products must undergo a mandatory external security assessment;
all Class II products are required to do so, while Class I
products must
only if they do not
follow the (not yet defined) "harmonised standards, common
specifications or cybersecurity certification schemes
".
The release-related documentation needs to cover (among other items) the
product's
expected uses, its support time frame, and the way to install security
updates.
All manufacturers must have a vulnerability-reporting procedure and
release security updates free of charge
for users. If a manufacturer learns about an
"actively exploited vulnerability
", it is expected to notify
authorities rapidly (24 hours
in many cases; followed by a complete analysis one month later). Finally, a
party
not complying with the requirements may be subject to fines of up to
€15-million or
up to 2.5 percent of the worldwide annual turnover (gross revenue),
whichever is higher.
Commercial activity
As the devil is in the details, definitions
have an important impact on understanding the CRA. The most
important term
is, without a doubt, "commercial activity
" as found in the following sentence:
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.
The definition for "commercial activity
" comes from a document called "The
Blue Guide",
which has examples on page 21 that provide a little more
explanation. The text
states that commercial activity means providing goods in "a business
related context
"
and the decision if a particular activity is commercial or not should
be done:
on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context.
Without further clarification, one might consider many open-source projects as commercial activities, especially mature ones that are used widely and make regular releases. Those with developers hired to work on the project might also qualify.
The definition of commercial activity is the main point affecting open-source projects. It will not affect hobby projects run by unpaid volunteers only. It could (depending on the any future judgments) affect all others. If that wording is not changed in the final version of the CRA, it could cause uncertainty, leading to lesser involvement in open source.
Who is the manufacturer?
The discussion of commercial activity brings us to the other
primary term of the CRA: the "manufacturer". Again, according to the
"Blue Guide" (page 34):
"The manufacturer is any natural or legal person who manufactures a
product or has a product designed or manufactured, and places it on
the market under his own name or trademark
".
The CRA also defines other roles like the distributor or importer, but
"manufacturer" will be the most important one in our case. The
manufacturer is critical
because they are responsible for fulfilling requirements and could
face the fines mentioned above.
Let us take the example of a project hosted by an open-source foundation. That foundation could be considered the manufacturer, even if it might have limited impact on the development process and concentrates on governance and organizational aspects. The definition of the manufacturer might be even more complicated when there is no formal legal entity. Is the person tagging a release the manufacturer in this case? The person with the most commits? All the maintainers together? Their employers?
If foundations or other supporting organizations are to be classified as manufacturers, they will be required to put additional constraints on projects and how they develop and release. That could cause significant tension, especially for projects with no established security culture.
Another point is the need for a budget in case an external assessment is required; currently, operating systems and networking software both require an external assessment. A typical budget for a security assessment is in tens of thousands of dollars (or euros). The exact scope of the audit for CRA requirements will be defined further (the general description appears in Annex VI), but we might assume a need for a similar budget for every non-bugfix release. It will be vital for many projects to figure out who will pay for assessments. Many of them, including virtually all without an organization backing them, will not be able to pay that fee.
Even if a project falls under self-assessment only, its release must be accompanied by several documents, including a risk analysis. Writing and verifying this information would mean additional work for projects, though the exact content of this documentation still needs to be fully defined.
Vulnerability and exploitation reporting
Under the CRA, each manufacturer needs to have a vulnerability-reporting process and, in most cases, provide security updates. Logically, they would also have to provide updates of all dependencies, especially when they are linked into the main product. A recent discussion in the Linux kernel community showed that timely delivery of security fixes is not yet a solved problem; regulation like the CRA might actually push device vendors to publish fixes more rapidly.
One clause also requests all manufacturers to report each
"actively exploited vulnerability
" whenever they learn about
it. The report must happen
within strict time limits, such as a first notification in 24 hours
(though it is not required for small companies). The company should provide
a detailed
analysis with a fix within one month. These reports are sent to the European Union Agency for
Cybersecurity (ENISA). With that pile of 0-days, ENISA will become
a juicy target for attacks (though one might argue that a service like GitHub's
private advisories is already
such a target).
The obligation to notify about all issues also breaks normal disclosure processes. These days, vendors disclose vulnerabilities only after a fix is available. Also, the one-month limit for a complete analysis might sometimes be hard to meet. The industry typically uses 90 days, but some vulnerabilities (notable examples include hardware issues like speculative execution bugs) take months from the discovery to the fix.
The reaction
After the original proposal was published in September 2022, the open-source community started rapidly responding to it. One of the first reactions came from a foundation, NLnet Labs, in a blog post describing the impact on its domain: network and routing protocols. Many of the projects the foundation works on fall into the "critical products" category and would require significant additional work, possibly including an external security audit. Also, they note that some of these tools, which may have been available for dozens of years, could be considered "commercial" so they would fall under the regulation even though the organization gets no income from that software.
Other organizations have done their own analysis as well. A blog post from Mike Milinkovich of the Eclipse Foundation lists all of the documentation and assessment that the Foundation would have to do for each released software version; he also mentions the uncertainty of which tools would be classified as critical or highly critical. During FOSDEM 2023, a panel (WebM video) took place where European Commission representatives answered questions from the community. This session mostly concentrated on the impact of the definition of "commercial activity" that is a condition for the product to fall under the scope of the CRA. It was said that even for charities, it is going to be case-by-case determination. Also, a Commission representative said that the goal of the regulation is to force manufacturers to do more due diligence on the components that they include; they will be obligated to do so as part of their security assessment.
In April 2023, multiple organizations released
an open letter
asking the Commission to "engage with the open source community and
take our concerns into account
". In addition, some specialized communities
such as Content Management Systems (CMSes) wrote
their own
open letter, which was signed by representatives of WordPress, Joomla, Drupal, and TYPO3. Interested
readers may also want to look at the list
of reactions that is
maintained by the Open Source
Initiative (OSI).
Possible response
If the regulation is put in place in its current form, some projects may not want to risk being classified as "commercial activity" and may decide to state that their code will not be available to the EU (enforced by technical means or not). That also raises interesting licensing questions; for example, it is not clear that GPL-covered code can have such a restriction. When code is restricted in that way, the security assessment for any downstream projects using that project in the EU will become more complicated — it could even mean that each downstream project needs to perform that audit independently. Or remove the dependency.
Some projects might decide to stop accepting contributions from developers employed by companies, or not take donations from companies, in order to not be classified as commercial. That could seriously impact those projects, reducing both their funding and the development base. But, even if such a project falls under the non-commercial category, downstream users might be using it otherwise.
Finally, there may be an impact on the number of new open-source projects. Convincing a (big) company to open-source new work is a daunting task; if there is more burden related to liability and documentation, fewer companies will release projects that are not crucial to their goals. This could affect tools like those for testing, continuous integration, for programming embedded devices, and so on. An increase in the number of forks is also likely; companies may want a version of some project's code with changes for CRA compliance. That could in fact decrease overall security, instead of improving it.
The current state
In addition to the initial version, as of August 2023 there are currently two sets of amendments, one from the EU Council, and another from the EU Parliament, that resulted from the work of Parliament committees. The most recent vote in the EU Parliament committees took place in July 2023. The next step is negotiations (called a "trilogue") between the Council, Commission, and Parliament to come up with a final version.
The two set of amendments change certain details, but not the
general thrust of the regulation. Both of them change lists of the
"critical product with digital elements
" (those that might require an
external audit). The amendments from the Council shorten both lists,
while ones from the Parliament move all routers
to Class II and add new categories to Class I (home automation, smart
toys, etc.).
They also both modify the "open-source exception". The Parliament
version seems to move requirements
to companies and gives a set of examples of commercial and non-commercial
activities. An indication of a non-commercial activity is a
fully distributed model and lack of control by one company.
On the other hand, if "the main contributors to free and open-source
projects are developers employed by commercial entities and when such
developers or the employer can exercise control
as to which modifications are accepted in the code base
", that is an
indication of commercial activity, the same as regular donations from
companies.
It also states that individual
developers "should not be subject to obligations pursuant to this
Regulation
".
The Council's version seems to cover more products by
the exception:
this Regulation should only apply to free and open-source software that is supplied in the course of a commercial activity. Products provided as part of the delivery of a service for which a fee is charged solely to recover the actual costs directly related to the operation of that service [...] should not be considered on those grounds alone a commercial activity.
The start of the negotiation on the final version is likely to happen after the summer break (which means in September 2023). Note that European Elections will happen in early June 2024 which means that the process is likely to be rushed to completion before that date.
The outcome?
Improving the security state of the digital world is a worthy goal, and many ideas the CRA brings are reasonable best practices. However, the impact of the current form of the regulation is difficult to predict. In the open-source world, it could be putting all the burden on upstream projects. These projects are frequently underfunded, so they might not have the resources to perform all the required work; that analysis and documentation work is worth doing, but funding has to be available in order to make it happen. FOSS developers, especially those working in the embedded space, should be paying attention to this legislation, as there is more to it than our summary above covers. Readers in the EU may want to contact their representatives about the CRA, as well.
| Index entries for this article | |
|---|---|
| GuestArticles | Rybczynska, Marta |
Posted Sep 19, 2023 19:44 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (6 responses)
Because in this whole discussion I get the feeling that there's a lot of reaching for worst case scenarios and looking for interpretations of words that seem pretty far-fetched. The scope here is severely limited by treaty and other acts.
I appreciate the update though, and the article is a nice summary of the current situation.
Posted Sep 19, 2023 19:57 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
Eh, think of the law as being written in an ambiguous, badly-scoped programming language. Sure, there's the nominal intent of the law, but there may be unintentional (or for the cynical, intentional) side effects that might only crop up in some specific corner cases. It just so happens that developers of F/OSS seems to heavily intersect this time.
Just because the current crop of politicians/courts/etc can be trusted and is "reasonable" doesn't mean their successors will be. History has shown us over and over that bad actors can and will take advantage of these fuzzy grey areas, and it's always the relatively powerless that pay the price.
Posted Sep 19, 2023 21:20 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Posted Sep 21, 2023 8:44 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Yeah, but if they are (or act) merely incompetent or clueless, words with precise meaning are the last resort of the competent.
Posted Sep 19, 2023 22:09 UTC (Tue)
by ghodgkins (subscriber, #157257)
[Link]
[1] https://blog.opensource.org/the-ultimate-list-of-reaction...
Posted Sep 20, 2023 4:42 UTC (Wed)
by mrybczyn (subscriber, #81776)
[Link] (1 responses)
Posted Sep 21, 2023 15:52 UTC (Thu)
by jajpol (subscriber, #8044)
[Link]
Posted Sep 19, 2023 20:59 UTC (Tue)
by florianfainelli (subscriber, #61952)
[Link] (1 responses)
The one positive outcome that I see is that if you had a company who was just aggregating open source software and packaging that as a product, possibly on top of hardware, now they have a responsibility into addressing security issues. Before that point, only their reputation was at stake but they could have been largely free loaders. Now they need to have a more active role and realize the cost of using open source (or not) software components in their products and take some amount of ownership into ensuring they are somewhat secure.
There is a big unknown with the timing and boundary aspects of "shipping free of vulnerabilities", by the time the product is out of the door, there might already be a vulnerability discovered in the version of the Linux kernel that you just shipped with. Products can stay on shelves with their manufacturing firmware for weeks, maybe months until inventory is sold.
I cannot shake the feeling that this act has been heavily lobbied by European companies in the certification/compliance business under the flawed pretence that consumer experience will improve and the world (or the EU at least) will be a better place for people to use their electronics. This appears to be a response to the EU having seen a sharp decline in manufacturing popular consumer electronics products (specifically phones, tablets, computers). As such, making certification harder for other economies (China, US, etc.) to sell to the European market is perceived as a way to grab a share of the pie that has escaped the EU for years. What I suspect will happen is that some companies may skip a version of two or their products since the cost of doing business in the EU will be judged too high.
So all in all, if you look at it, this is going to be a form of a tax imposed on manufacturers, but paid by the consumer, because no company will ever eat into their profit and give you the certification cost for free.
It seems to me we would have a better chance at improving the overall industry if we were to fine companies for failing to address security vulnerabilities that they had been made aware of. It teaches a lesson to anyone in the industry and reminds you that you cannot just accumulate profits and walk away.
Products that are absolutely mission critical should hopefully already be under similar legislation, if not, then clearly they should be the prime target, because nobody needs their ultra sound or MRI machine to be ground zero for a hospital hack.
My 0.02€
Posted Sep 20, 2023 8:26 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
I would just note that it's meant to "increase the cost of doing business". Right now, businesses get to push the cost of dealing with security onto everybody else, including people who aren't their customers; for example, if your business shipped an industrial tool 5 years ago that's now out of support and that has a security hole that's used to attack my home systems, that's my problem, even though I didn't buy anything from you.
The goal of the CRA is to push those costs onto the businesses that have a way to prevent them. In my example, you'd be on the hook for fixing that problem. For businesses that already care, this imposes a small cost in the bureaucracy of showing compliance; for businesses that don't care, you've now got to spin up the infrastructure to support in-the-field software updates, the engineering team(s) to provide such updates on a timely basis, and the additional bureaucracy.
Posted Sep 19, 2023 21:03 UTC (Tue)
by flussence (guest, #85566)
[Link]
Posted Sep 19, 2023 21:07 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
There doesn't seem to be much disagreement between the two texts, but it's going to take a lot of word-smithing to get this down to a single document. Both the Council and the Parliament drastically changed the paragraphs relating to free-software in largely compatible ways, but someone needs to work them down do a single version both agree with.
Posted Sep 19, 2023 21:48 UTC (Tue)
by dullfire (guest, #111432)
[Link] (11 responses)
That being the case, I wonder if that would effectively make use of GPL'd projects that originate outside the EU (where these requirements do not exist), in works by parties inside the EU a breach of the GPL.
PS. I am not a lawyer. And definitely not one for EU related maters.
Posted Sep 19, 2023 22:10 UTC (Tue)
by pizza (subscriber, #46)
[Link] (6 responses)
Why wouldn't this apply equally to GPL'd projects written from within the EU?
After all, it's not the national origin of the software that matters; it's whether nor not it comes with the necessary paperwork?
Posted Sep 19, 2023 22:25 UTC (Tue)
by dullfire (guest, #111432)
[Link] (5 responses)
To put another way: The reason I don't think it would be a GPL violation for an in-EU author is the author would directly (potentially) be held liable. Where as an external project only has a nexus to the author via their GPL license.
Anyhow. Not a lawyer. Just musing that I think that goes against at least one part of the GPL's terms (the prohibition on adding terms)
Posted Sep 20, 2023 13:43 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (4 responses)
Or it could be a simple case of "intersection of requirements". If the GPL imposes one set of requirements (that you pass on everything you receive) and the law imposes a different set of requirements (if you give a product to someone, you must provide a warranty), then there is not necessarily any conflict. Just because the GPL says "this software comes without warranty" doesn't mean it conflicts with "the law says you must provide a warranty". The legal warranty you provide is totally irrelevant to the fact that software has no warranty.
It's actually very similar to the copyright/patent situation. Just because patent law may say "you can't use this software", it has no impact on the GPL saying "you may freely share AND USE this software". The software authors have given you the right to use the software, the fact that the law says exercising that right is illegal under a different (patent) legal code is irrelevant to the GPL. v2 at least, v3 attempts to address this.
Even with ITAR and arms regulations etc etc, if the GPL allows you to freely distribute "illegal" software, you're in the clear as far as the authors of the software are concerned. Doesn't stop the government coming after you for distributing "illegal munitions", but it's nothing to do with the GPL.
Cheers,
Posted Sep 20, 2023 13:44 UTC (Wed)
by paulj (subscriber, #341)
[Link] (3 responses)
Posted Sep 20, 2023 14:05 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
I was thinking of the case where requirements collide.
Actually, I think I can now word it far better. The GPL places requirements on the GIVER. The law places restrictions on the RECIPIENT. Where this is the case there can be no GPL violation. And, in this particular case, I think this is the actual state of affairs.
Americans are free to distribute GPL software into Europe, CRA or no CRA. If it's not been advertised in Europe then there is no "placed on the market", and it's a grey import.
Europeans are then free to distribute it, provided they comply with the extra legal burden of the CRA. And the GPL has no say here, because the "additional requirement" of complying with the CRA is not being passed on by the giver, but is imposed (or not) by the law.
Cheers,
Posted Sep 20, 2023 14:23 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
As currently drafted, simply being *made available* (even for zero cost) to an EU citizen is sufficient to be considered "placed on the market" for purposes of the CRA.
When the various proposed changes are reconciled together, we shall see what the new text says... But until then...
Posted Sep 20, 2023 15:26 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Hmmm ... that's scary.
Because as I understand it, "placed on the market" is a term of art defined elsewhere in other (consumer protection?) legislation, and if the CRA is re-defining it, then that is a massive change - far bigger than just cyber-security and what-not.
Cheers,
Posted Sep 19, 2023 22:44 UTC (Tue)
by jkingweb (subscriber, #113039)
[Link] (2 responses)
Posted Sep 20, 2023 11:12 UTC (Wed)
by mrybczyn (subscriber, #81776)
[Link] (1 responses)
I haven't checked that interpretation with lawyers.
Posted Sep 20, 2023 12:31 UTC (Wed)
by pizza (subscriber, #46)
[Link]
I don't see why; Nothing forces the software author to make the softare available to everyone in the world. If the author blocks EU IP addresses from their download side, that's not a GPL restriction.
Now if someone _else_ distributes the software within the EU -- say, Debian, will Debian face liability?
(FWIW, I have a really hard time seeing how any major Linux distribution could continue to exist under the CRA. Or should only RHEL or SLES face liability because those are commercial products, but CentOS/Fedora or OpenSUSE/Tumbleweed not be, as they're provided Gratis, As-Is?)
Posted Sep 20, 2023 8:23 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
There are already additional requirements in the USA on software that's distributed there under the GPL (notably FCC spectrum requirements for WiFi chips). If those restrictions qualified as "you cannot redistribute the covered work", then you could not ever have distributed a WiFi driver in the USA for any driver that allows software to have some say in which frequencies it uses (which covers all SoftMAC WiFi chips, for example).
Secondly, the text of the GPL does not prohibit you from distributing if additional requirements apply to you; it prohibits you from imposing additional requirements beyond the GPL on downstream recipients. It also says that you are only blocked from distributing if the additional requirements conflict with the GPL. In this case, you are not imposing a liability requirement on downstream (that's coming from the law), so you're not blocked by the "no additional requirements on downstream". You're also not facing requirements that conflict with the GPL; the GPL does not say "you must not accept liability for software you distribute", and thus you're safe on that count.
Posted Sep 20, 2023 3:58 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (23 responses)
Software development in EU might be living its last few years.
Posted Sep 20, 2023 12:16 UTC (Wed)
by corsac (subscriber, #49696)
[Link] (12 responses)
Posted Sep 20, 2023 22:51 UTC (Wed)
by neggles (subscriber, #153254)
[Link] (11 responses)
> Products provided as part of the delivery of a service for which a fee is charged solely to recover the actual costs directly related to the operation of that service [...] should not be considered on those grounds alone a commercial activity.
That sounds like an out for SaaS to me.
Posted Sep 21, 2023 6:15 UTC (Thu)
by znix (subscriber, #159961)
[Link]
Posted Sep 25, 2023 15:44 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (9 responses)
In other words, if I provide a bunch of download servers, which distribute stuff (product) other people supply, no liability attaches to me.
Think a delivery operation, like eg Federal Express. Okay, I guess they have a duty of care to avoid distributing illegal stuff like drugs, but for the most part they are the courier with no obligations beyond safely moving stuff around. Said "stuff" is for them an opaque box.
So if a distro merely packages upstream (yes I know distros typically do more :-) and distributes it, then they are free to run that as a business without incurring liability.
So what we need is the clear chain that says the writers are under no obligation because they provide it with no warranty. The distributors are under no obligation because they are merely aggregating everything into a convenient package.
Liability needs to start at the point a "manufacturer" includes this stuff in a PHYSICAL product. Because it's at that point the RISK also really starts.
Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
Even if I start distributing it, the user-base will be small, and the blast radius insignificant. But if a manufacturer spots my product and "places a product on the market" (as per the blue book, I think it is), this is where the blast radius becomes significant, and this is also where the CRA needs to bite.
One of the simplest ways to protect the small-time coder would be the rule "No contract? No transfer of liability!" Then in, let's say, pizza's case he can warrant that his software will behave to spec, and if it doesn't he'll fix it. If the spec is wrong, not pizza's problem. If there is a vulnerability, pizza gets to fix it. It's the product manufacturer's responsibility to get that bugfix to their customers in a timely manner - indeed - to have a manner of issuing bug-fixes!
(Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
If manufacturers want to graze the software commons, they accept the liability that comes with accidentally picking poison mushrooms ...
Cheers,
Posted Sep 25, 2023 15:59 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
SaaS *would* be covered by the CRA. They aren't just providing you with a copy of a piece of software that they got from someone else, They're providing you with a whole lot more. It's not a case of "you can get that from anywhere, we just provide it all neatly packaged".
Think the difference between an editor and a printer. Give your book to a printer, and you get back multiple copies of your book. all identical copies of the original you handed over. Give it to an editor, and you get *roughly* the same thing back, with (hopefully) the grammar and punctuation cleaned up, the layout redone, a nice professional cover, etc etc.
One company learned the difference between a printer and an editor the hard way. My English master sent the school magazine to them to PRINT. They promptly reset it in their own house style, and then expected to be paid. The English master had a fit and refused point blank. When the printers threatened to sue he pointed out they didn't stand a hope in hell of winning because, if they were PRINTing what he'd sent them, the goods were not what he asked for and not fit for purpose. And if - as they had - they took it upon themselves to edit it, they took upon themselves the risk it would be a flop, as it was, as the English master refused to pay.
Oh - and not fit for purpose. It was a SCHOOL magazine. And the School's definition of "correct" English was the relevant Local Exam Board - Oxford, as it happens. The printer's house style was, according to the exam board, "wrong", and would have cost the students marks had they copied it.
Cheers,
Posted Sep 25, 2023 22:51 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52022PC0454
You need BOTH documents on that page, they work together.
SaaS is NOT covered. The CRA defers to a new, yet-to-be-written, similar Regulation or Directive. That Regulation/Directive will be similar in spirit to the CRA.
Cheers,
Posted Sep 28, 2023 11:38 UTC (Thu)
by kleptog (subscriber, #1183)
[Link]
I do encourage people to do this. The original article above actually links directly to the original version (first link) and the amended versions by the Council[1] and Parliament[2] (under current state), so you can get an idea of where this is heading.
If nothing else, read just the recitals that come before the articles. While not explicitly legally binding they do provide guidance as to the how and why of the Act. They are written in straight-forward English and in the case of any ambiguity, the recitals make the difference. They also go into way more detail about how this is intended to work.
If you're into software design, the recitals are the equivalent of requirements & use cases.
Repeating the links in case people missed them.
[1] https://data.consilium.europa.eu/doc/document/ST-11726-20...
Posted Sep 25, 2023 16:13 UTC (Mon)
by pizza (subscriber, #46)
[Link] (5 responses)
So in other words, Microsoft will face zero liability for defects found in Windows, as long as they don't supply any hardware.
>Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
Are you really sure that you don't care that you "bear the brunt of it"? After all, we're talking about potential financial ruin here, with no upside.
> (Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
Are you sure about that? That just means the hardware "purpose" will get dialed way back until all it's legally "fit" for is along the lines of "it takes up space, blinks a couple of lights, and won't electrocute you." And if you want it to do anything more, you'll have to look elsewhere for the software. Not unlike today when you can buy a motherboard or even a complete barebones PC without any OS. It's no longer a "complete product" but a "kit" that requires the user to assemble or otherwise complete. And the user bears all responsibility for the consequences.
Posted Sep 25, 2023 17:17 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Liability starts at the point something is included in a physical product today. The point of the CRA is to push liability backwards down the chain until either you get to a creator, or you leave the world of commercial relationships, and to add liability for things that occur "in cyberspace".
So, in a CRA world, Microsoft is liable for defects in Windows, because you can't get Windows legally via any route other than a commercial deal with Microsoft. Similarly, hardware makers are liable for the software they include with the hardware, and for ensuring that the hardware is supplied with sufficient software to make the hardware useful for the claimed purposes of the system. This means that if I sell you a "car", it's got to function as a car - and if you have to install software to make it function as a car, then I'm required to bundle that software with the car (and thus be liable for it). I could sell you a "kit of parts" that you need to assemble, but then I can't do anything that might make you think I'm selling you a car, just a set of parts that don't work for any purpose.
Similarly, in the CRA as it currently stands, me putting my pet project up on GitHub, or publishing it on my website, or selling tapes with the source code on at the cost of the tape plus shipping, does not make me liable for flaws in it. Only the selling tapes is a commercial transaction, and the CRA as it stands has an exception where I'm doing that at cost. If it's awful, and blows up in my face because it's so vulnerable, that's my problem to deal with - I'm liable for the damage my systems do, and it's my code on my systems. But because you have no relationship with me that would make me liable to you for flaws in my code that I gave away for free, without so much as a service contract, if you take a copy of my code and run it, you're still liable for the damage your systems do, and you don't have a relationship that lets you push that liability back to me.
Posted Sep 25, 2023 17:50 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (3 responses)
> So in other words, Microsoft will face zero liability for defects found in Windows, as long as they don't supply any hardware.
So maybe I shouldn't have said "physical". I think MS is a manufacturer and Windows is a "product placed on the market" according to the Blue Book, so as things stand they're liable. And are you sure you don't want things to change? Because that could kill MS' pre-installed monopoly just like that, so that actually could be a good thing. It would mean all of a sudden people would start installing linux left right and centre because they would see the real cost of Windows. :-)
> >Who cares if my pet project is vulnerable as hell? So long as it's just me, it's the same liability as the lone inventor tinkering in his shed with things like gas bottles. Any disaster will be localised, and I'll bear the brunt of it.
> Are you really sure that you don't care that you "bear the brunt of it"? After all, we're talking about potential financial ruin here, with no upside.
And that's different to the current situation how? Given the current propensity of Americans to sue anybody (including foreigners) for anything, I think having a rich American take a dislike to you will leave you facing potential financial ruin whether you're a saint or a devil.
No I'm not downplaying the risks. But life is a game of Russian Roulette, and given that the CRA is a gun that probably won't fire, I've got rather more important things to worry about. Life is a fatal disease, don'cha'no?
> > (Oh, and I don't think pizza needs to worry about manufacturers saying "go download this software from over there". If the product needs the software to function, and the software malfunctions, that's "not fit for purpose", which brings a world of hurt on its own.)
> Are you sure about that? That just means the hardware "purpose" will get dialed way back until all it's legally "fit" for is along the lines of "it takes up space, blinks a couple of lights, and won't electrocute you." And if you want it to do anything more, you'll have to look elsewhere for the software. Not unlike today when you can buy a motherboard or even a complete barebones PC without any OS. It's no longer a "complete product" but a "kit" that requires the user to assemble or otherwise complete. And the user bears all responsibility for the consequences.
And nobody will buy it. Which might be a bloody good thing.
You said something about not being European. Well, Europe doesn't tend to indulge in all these nasty extra-territorial shenanigans that some other countries hint hint like to do. Keep out of Europe, and the CRA can't touch you. Even if it touches your software, the authorities will go after the people who recklessly imported it, not you.
Something I'd like to know. You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA? Because when I was looking, I've mentioned the "Blue Book" before (which someone else here pointed me at), and if you're right and the CRA is trying to redefine the term, I think we're in for a far bigger world of hurt than just computer security. You're looking at this far too much in isolation. As others have said, this interacts with tax law. I've made repeated references to the Blue Book and Consumer Protection legislation.
Yes, there is no upside to being sued. And no there is no defence against some random guy trying to sue you. For ANYTHING. But in any jurisdiction where Equity is important, like the UK, like I suspect most of Western Europe, you'll get off much more lightly than anywhere else in the world.
If some random company sued me under the CRA, my reaction would be to ask the Judge what grounds do they have to sue me, because their suit should be illegal under the slavery acts. So what if that argument doesn't legally fly, if the Judge thinks yes I have a real case, that argument makes sense, said random company is pretty much certain to lose provided I line my ducks up properly. What's worse, they'll probably end up paying for my target practice.
You said your side business enabled you to keep a roof over your head when $dayjob let you down? In other words, your side business saved you from financial ruin? So there's a hell of a lot of historic upside - it's proven it can save you from financial ruin - TWICE. Don't you think a current score of 2-nil says it's worth the risk?
Or are you - like a lot of people actually - so focussed on the pessimistic downside that you'll actually happily ruin your life trying to avoid a possible imaginary disaster? What a STUPID waste.
I can't say there's no risk. But as it says in the Flanders & Swan song ... "here in a nuclear testing ground, is no place to bury your ..." Live for NOW, write PROPERLY DESIGNED software, and try and keep your nose clean. Unfortunately, we all have no control over being dragged into the legal sausage machine, so don't worry about what MIGHT happen (other than to watch out for really stupid laws).
Cheers,
Posted Sep 25, 2023 20:55 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
I don't consider it a good thing if it also destroys the ability for F/OSS projects to accept any sort of commercial funding.
>And that's different to the current situation how?
In my documentation, I explictly state: "This free software comes with ABSOLUTELY NO WARRANTY and is licensed under the GNU GPL (v3 or later); see the 'COPYING' file for more details." And later on, "[this software] may have half-developed features that don't quite work, with giant bugs that come out at midnight to eat your cat."
The social contract underpinning this is that I give this software away freely, but at the same time, you have no recompense if it doesn't work. The CRA changes this implicit contract so that you (and everyone else who downloads that software) *do* have grounds to demand recompense, without giving *me* some sort of proportional benefit.
> Well, Europe doesn't tend to indulge in all these nasty extra-territorial shenanigans that some other countries hint hint like to do.
I assume you've heard of the GPDR? That is explcitly extra-terroritoral. This will need to be as well, or it won't be worth the paper it's printed on.
(Meanwhile, my previous two employers were subsidiaries of European companies, and one involved a lot of travel to the EU. My current employer will probably be acquired by an EU company. So I'm probably not going to escape from this without ditching _something_)
> You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA?
There are several blanket exemptions in the CRA for F/OSS activities, but the act of money changing hands eliminates most of them. Accepting donations to cover costs? That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!) Accepting funds for anything other than covering costs, eg a feature or bug bounty? You're now commercial. Run an actual business that provides servive, support, and other such things? Bingo! It doesn't matter if the money is for software or services, if it's directly related, or even _how much_ revenue you take in that's related to that software. It only matters that you're conducting some sort of commercial activities while providing software, which makes you into a manufacturer with obligations enforced with massive punitive penalties.
Posted Sep 25, 2023 21:59 UTC (Mon)
by kleptog (subscriber, #1183)
[Link]
Eh, no. You're talking about liability and you can only have product liability with respect to someone you have a direct commercial relationship with. Just because you receive some money from someone, doesn't mean suddenly you suddenly have a commercial relationship with everyone in the world. If you don't want to provide any warranty, that's fine. Just tell them that any version not the latest may have security bugs and they must upgrade immediately when there's a bugfix. As an open-source project this is trivial to arrange.
> That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!)
The thing is, most F/OSS projects are not delivering a product to market. They're publishing source code, which isn't a product by itself.
> It doesn't matter if the money is for software or services
Ofcourse it matters. Services are not covered by the CRA, products are. The normal approach with F/OSS is that the software is free and the services are not. So the software is delivered non-commercially as open-source download, together with commercial services. It's probably a good idea to make that clear in your contract.
Now, the Apache Project selling OpenOffice online, that sounds like it might be a problem. Isn't that supposed to be super buggy?
Posted Sep 25, 2023 21:59 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
> I assume you've heard of the GPDR? That is explcitly extra-terroritoral. This will need to be as well, or it won't be worth the paper it's printed on.
Extra-territorial in what sense? How is the EU going to prosecute an American company, or American people? They can prosecute them if they are based in the EU. And it's the EXPORT of the data that matters. (Which is why and how American companies get clobbered, if they export the data of the European employees / customers.) And even for American companies like Google, they are operating in the EU, therefore they have to abide by European law.
In order to break the law, you HAVE to be in possession of personal data belonging to Europeans.
It's like some British sexual abuse laws - they apply to all Brits, no matter where the offence took place. But you need that connection with Britain.
This is very unlike America, where they will extradite Brits for doing stuff - in Britain - that is perfectly legal under British law.
> (Meanwhile, my previous two employers were subsidiaries of European companies, and one involved a lot of travel to the EU. My current employer will probably be acquired by an EU company. So I'm probably not going to escape from this without ditching _something_)
> > You said the CRA defines you as "offering a product" which makes you a "manufacturer". Where on earth did you find that in the CRA?
> There are several blanket exemptions in the CRA for F/OSS activities, but the act of money changing hands eliminates most of them. Accepting donations to cover costs? That's fine, unless that donation is from a recurring corporate sponsor. (which hits quite a few larger F/OSS projects!) Accepting funds for anything other than covering costs, eg a feature or bug bounty? You're now commercial.
> Run an actual business that provides servive, support, and other such things? Bingo! It doesn't matter if the money is for software or services, if it's directly related, or even _how much_ revenue you take in that's related to that software. It only matters that you're conducting some sort of commercial activities while providing software, which makes you into a manufacturer with obligations enforced with massive punitive penalties.
But here you are taking *payment*, YOU HAVE A CONTRACT, because you have a mutual exchange of money for agreed benefits. Whereas if you were taking donations, where on earth does it say that's a commercial relationship? If there's no goods or services agreed going in the other direction, how on earth are they going pin anything on you.
And you STILL haven't pointed at where - in the draft CRA - all this stuff is. Is it because it isn't actually there?
I still can't believe the CRA is trying to redefining the meaning of "commercial transaction" or "offering a product". And if it isn't, then most of what you're worried about is scaremongering.
Cheers,
Posted Sep 20, 2023 12:40 UTC (Wed)
by pizza (subscriber, #46)
[Link]
This will be the most likely outcome, along with completely gutting F/OSS creation and general purpose computing in the EU.
This will increase software (and thus product) development costs by at least an order of magnitude, and will also effectively create a giant step from purely-as-a-hobby-with-no-obligations to manufacturer-under-the-CRA-with-full-obligations, with no middle ground.
Posted Sep 20, 2023 15:19 UTC (Wed)
by shemminger (subscriber, #5739)
[Link]
I remember when ISO9000 was going to solve all software quality problems through more process. And see how well that worked.
There is a real problem here, but this is not a solution.
Posted Sep 20, 2023 21:56 UTC (Wed)
by kleptog (subscriber, #1183)
[Link] (7 responses)
Notifications only apply to security issues found in deployed products, so not every bug needs notification. This actually ties into the discussion that was here recently about when CVEs should be allocated. This Act cannot solve this problem (nor does it try). If you want to reduce the impact of this Act, then it would be a good idea to stop assigning CVEs for issues that aren't important.
Posted Sep 21, 2023 2:25 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (6 responses)
The problem is that it's not the developer's job to try to figure if a bug may possibly have security ramifications or not. The developer makes a bug and fixes a bug.
> If you want to reduce the impact of this Act, then it would be a good idea to stop assigning CVEs for issues that aren't important.
That's one of the likely outcomes, that everyone strongly refuses to assign any CVE on the grounds that "no, it's not a security problem, in the worst case it's a misuse" at least to try to escape the CRA.
Posted Sep 21, 2023 11:35 UTC (Thu)
by kleptog (subscriber, #1183)
[Link]
Correct, which is why notifications are only required for vulnerabilities that are known to be actively being exploited. Potential vulnerabilities are of not interest here because as you point out, you just need to push the bug-fix out to people in a reasonable time-frame and spend no more time on it. The goal here is to prevent suppliers sitting on information about actively exploited vulnerabilities. You can voluntarily notify about other things your customers may be interested in. I don't see how this is a big change compared to what people are doing now.
Posted Sep 22, 2023 5:10 UTC (Fri)
by ebee_matteo (subscriber, #165284)
[Link] (4 responses)
I strongly disagree and I think this is at the root of the problem.
The CRA is written *exactly* because we see a severe uptick in exploitable vulnerabilities because developers do not care enough about security as part of project development.
In turn these are widespread enough that they are very juicy for a state-actor threat or rogue terrorist.
The spirit of the CRA is: you *need* to care about this. If you do not directly have the resources as an hobbyist, at least companies commercializing those products need to allocate proper resources and FTEs or face the consequences.
The free ride has ended.
You do not like this? Keep unreviewed software out of your commercial product that can have potential repercussions on the life of millions of people.
Unfortunately it is currently very visible for people on the cybersecurity area how open source is becoming an easy target for a plethora of attacks, esp. socially engineered and supply chain related.
Big companies certainly have resources to foot the bill for code reviews and the paperwork needed.
Now, the language in the CRA needs fixing, I agree. But the spirit is correct.
Posted Sep 22, 2023 21:00 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
> I strongly disagree and I think this is at the root of the problem.
I'd put it rather differently, but yes it's because developers don't do their job properly.
> The CRA is written *exactly* because we see a severe uptick in exploitable vulnerabilities because developers do not care enough about security as part of project development.
> In turn these are widespread enough that they are very juicy for a state-actor threat or rogue terrorist.
> The spirit of the CRA is: you *need* to care about this. If you do not directly have the resources as an hobbyist, at least companies commercializing those products need to allocate proper resources and FTEs or face the consequences.
If you care about doing a good job, a lot of this grief would just go away. What's the quote? "If they built buildings like we build software, the first woodpecker to come along would destroy civilisation"? Most software is held together with duck tape, string, and sealing wax.
I'm very much with Linus here - "a bug is a bug is a bug. It should be fixed". Security considerations are secondary. But as I see it, there are two problems ... and I'm with him with his other quote too - "the best programmers are lazy programmers, they get it right first time because they can't be bothered to do it twice".
Firstly, most software today is not designed. It's thrown together, it works, and that's that. Then it gets extended and extended and the parts don't work together. Etc etc.
The second thing is, a heck of a lot of our tools suffer the same problem. C is a massive offender, with all its undefined behaviour. Landmines everywhere. I've just been fighting conditional formatting with VBA. Badly documented, things blowing up when you think they should work, things only make sense AFTER you've debugged the problem, ...
Again, what's that saying? "Ten minutes extra in the design phase knocks an hour off the debugging". I'm probably loved and hated simultaneously at work, because I spend so much time fixing technical debt even in the middle of a fire fight.
That's why I hate Word. That's why I hate Relational/SQL. I've worked with programs that have a clear, simple design. Things "just work". Everything I do, I try to step back and have a clear design behind it. Even if I do a half-baked implementation, so long as the design is simple, clear, AND WELL COMMENTED IN THE CODE, things are far less likely to break. If somebody tries to do something I haven't implemented, they should crash into an error message that says "not implemented, please file a bug report". They shouldn't crash into an undefined, unanticipated state that causes all sorts of grief.
How much effort is it to check a variable that says "these are the states I know about and can handle. Anything else, raise an error"? Okay, if the previous guy didn't do it you're probably into a world of hurt. But if all your code does it, you're not going to be responsible for some obscure security problem because you didn't do your job (if that other guy's code drops you in it, well sorry ...)
Cheers,
Posted Sep 25, 2023 2:33 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (2 responses)
That's exactly my point. Figuring how a bug might be used to participate to an exploitation chain requires a different mind and set of skills. Many developers will not see how missing a line feed at the end of an error message might constitute a vulnerability, it's just a cosmetic error, but some upper layer wrapper might rely on this specific delimiter and might get confused enough to be fooled. That's what I mean by "it's not the developer's job". The developer cannot know *all* possible use cases and integration of their creation. Of course, writing a blatant buffer overflow does have immediately visible security implications, but a lot of security issues nowadays stem from a combination of small escalations, sometimes from different components.
Posted Sep 25, 2023 7:32 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
But this is what really pisses me off (not only with developers, but ...)
If the developer is not knowledgeable enough (I carefully didn't say "skilled") to know that there is SUPPOSED to be a line feed, this is a failure on oh so many levels. A badly designed tool (the compiler?), an inappropriate language (okay that's often management), a developer satisfied with "oh it appears to work", an analyst who didn't analyse the job properly ... the list goes on.
At the end of the day we should be aiming to do the best job we can, and that does NOT mean patching broken tactics on top of broken tactics. Banging on about Pick again, but it's noticeable with Pick that good software tends to be implemented by teams, with domain experts specifying the problem and helping in the programming, while the computer experts help in the specification and make sure the programming is done properly.
At the end of the day, far too many problems are caused by "ivory tower syndrome" - epitomised by typical computer split into analysts and programmers, where analysts understand neither the subject nor programming, and programmers implement the spec they're given. A recipe for disaster. I hope most of us don't work in those sorts of environments, but it's those embedded attitudes that are responsible for a lot of the problem. I guess that can be summed up as "bureaucracy" :-)
Cheers,
Posted Sep 25, 2023 10:17 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Right, and nothing about the CRA stops you saying that all commits (not just all bugfixes, but all commits, whether they're known to be bugfixes or not) are security relevant; if you do this, then your downstreams have to either keep up with development, or accept the risk of being liable for bugs in your software if you've fixed one and they haven't taken that patch. The whole thing only becomes an issue if you're (a) providing software in a commercial context, (b) not wanting to force your customers to upgrade all the time, and (c) don't want to be liable for security-relevant bugs in the software; at this point, the CRA forces you to choose which of those three you drop.
Posted Sep 20, 2023 6:28 UTC (Wed)
by vegard (subscriber, #52330)
[Link] (1 responses)
Posted Sep 22, 2023 5:15 UTC (Fri)
by ebee_matteo (subscriber, #165284)
[Link]
Exploited us for when an attacker is already using it for their gain.
Posted Sep 20, 2023 7:13 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link]
Of course the initial drafts are going to be a mess, the legal side of software has been rotting for too long. However it is much better to write down that mess and try to put it into shape it than dump all the misunderstandings and ambiguities on individual judges each time some bit of software is involved in loss of life or property, and hope those individual judges will magically determine the right path no one trod before.
Note that regardless of the decision to write the Cyber Resilience Act or not the misunderstandings, ambiguities and FUD-ing exist today in real life and are one of the major reasons funding never seems to reach the people writing the software prosperous commercial entities depend on.
Ultimately, if you want to depend on software (in the cyber sense or not), you need to fund the people able to fix it. And not pretend some fairies will write the fix for free every time you hit a problem.
Posted Sep 20, 2023 11:02 UTC (Wed)
by jezuch (subscriber, #52988)
[Link]
But just bags of money would be nice too.
Anyway, we're focusing on potentially damaging impact on FOSS, but let's not forget the flipside. For example, we don't want to water down the language so much that it's trivial for companies to avoid scrutiny by falsely claiming to be doing open source. Also, as someone already mentioned, we definitely do want to increase costs for those who don't care (in order to make them care). It's the old problem of externalities, which is as old as capitalism (and probably older). The equivalent from the "old" world is a polluter who dumps waste into a community's drinking water reservoirs. This will not get fixed by markets, it can only be fixed by regulation. Yes, it increases the cost of doing business. But the health of the community needs to be more important than your business model.
Posted Sep 20, 2023 12:07 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (7 responses)
Simply put, root liability should lie with any organisation "placing goods or services on the market". This very clearly and explicitly (to my understanding) would exclude any and all developers (big, small, commercial, whatever) who effectively do a code dump and say "here's some open source code, make of it what you will". Placing on the market means you need a product, which you advertise, and presumably charge for (I don't think you have to charge, you could be giving it away in an advertising campaign, but there does have to be a clear exchange of value somewhere).
So let's say I made a router, and plonked OpenWRT on it. As soon as I advertise that router and sell it, or say "free with my ISP service", or whatever, I am accepting responsibility for that router (including the software on it). I need to get that software certified, whether I do it myself, or pay OpenWRT to do it, or employ some third party to do it.
But the crucial point needs to be that if I just download OpenWRT off the internet, NO LIABILITY transfers to the OpenWRT project. They've made a code dump available to all and sundry, and liability rests firmly with the downloader. Only if I come to some commercial arrangement with OpenWRT will liability transfer to OpenWRT (under the contract).
This will also (I think) cover Farnz's case of providing hardware and telling your customer to "download the free software off the internet". If my router only works with OpenWRT, I'm providing a product that is "not fit for purpose as supplied". Which means I'm still on the hook for any problems the customer may have.
Cheers,
Posted Sep 20, 2023 12:26 UTC (Wed)
by pizza (subscriber, #46)
[Link] (4 responses)
So, if you download OpenWRT and plonk it onto a router, is the original manufacturer liable, OpenWRT liable, or are you personally liable for a security flaw on the unit that gets exploited to attack $gov_facility?
It stands to reason that the manufacturer should be absolved here, unless by virtue of "allowing modifications" they then become complicitly liable. If you follow tha tline of reasoning then everything is going to be heavily locked down and protected by go-directly-to-jail DRM, effectively ending general purpose computing. It also stands to reason that OpenWRT should face _some_ sort of obligation/liability should they ship a dangerous bug that can be exploited. Or a router maker could just ship a software-less box and say "Get your software from somewhere else" to avoid liability. If the liability instead falls to the user because they're the ones who "modified someone else's product" then what's to stop the hw maker from saying "The user chose to install this software, they're responsible, not me!"
This is why this is such a thorny problem. How do you craft an exception for F/OSS activities in a way that doesn't absolve commercial players, when the definition of "commercial" is so broad that it essentially encompasses anything that's not done on a purely "disorganized volunteer that gets ZERO funding, not even banner ads on a web page" basis?
Posted Sep 20, 2023 13:53 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (3 responses)
> So, if you download OpenWRT and plonk it onto a router, is the original manufacturer liable, OpenWRT liable, or are you personally liable for a security flaw on the unit that gets exploited to attack $gov_facility?
$gov_facility is liable for not properly securing their site ...
My router is quite clearly NOT a "product placed on the market". I over-wrote the supplied firmware with OpenWRT. The manufacturer of the commercial router cannot be held liable because I mod'd it.
Likewise, OpenWRT just placed their software on the internet for anyone to download. I downloaded it, installed it, configured it, and quite possibly (probably?) messed up. OpenWRT can't be held liable unless I *bought* a pre-configured setup off them.
$govt may not like the fact that they are both liable, and the victim, but if the rest of us have to suffer that on a daily basis, why not them? What needs to be driven home to the legislators is that your vision of a world of locked down hardware is a dystopian cure even worse than the disease.
If manufacturers are forced to clean up the dystopian world of the "internet of things", the background security level will rise sharply.
Cheers,
Posted Sep 20, 2023 14:19 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Ah yes, they should face liability because they only paid for a 10Gbps connection instead of a 1Tbps connection capble of handling a DDOS.
> My router is quite clearly NOT a "product placed on the market". I over-wrote the supplied firmware with OpenWRT. The manufacturer of the commercial router cannot be held liable because I mod'd it.
So in other words, OpenWRT is not liable, the manufacturer of the equipment is not liable... which leaves you. But since you didn't "place this product on the market" you're not liable for any damage it causes either.
That seems... quite wrong.
What if it's not "you personally" but "you as the owner of a small business whose employee over-wrote that firmware and placed it into service with no access controls?"
> If manufacturers are forced to clean up the dystopian world of the "internet of things", the background security level will rise sharply.
Doing so by effectively outlawing general purpose computing and independent software development sounds like a pretty dystopian outcome to me.
Posted Sep 20, 2023 16:00 UTC (Wed)
by ebee_matteo (subscriber, #165284)
[Link]
No. You are privately liable under European (or EU specific-country law) for failing to secure properly your devices.
It's just not due to the CRA. It's law already in place.
Posted Sep 20, 2023 16:02 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
> That seems... quite wrong.
I agree with you. BUT. How different is it to anywhere else? Not at all, as far as I can tell. What if I buy a bunch of aftermarket car mods, rally-fix my car so it's totally illegal, and go road-racing with my mates?
It only needs a fatal smash and a bunch of innocent bystanders are left with no recourse because at best I'm a man of straw not worth suing - at worst I'm dead too (many people would think that was for the best! :-) and there isn't anyone to sue. Tough. That's life. And death.
> > If manufacturers are forced to clean up the dystopian world of the "internet of things", the background security level will rise sharply.
> Doing so by effectively outlawing general purpose computing and independent software development sounds like a pretty dystopian outcome to me.
And the alternative is?
It's a "damned if you do, damned if you don't" world out there.
Stuff needs to be field-updateable. Stuff needs to have the code available for audit.
I'd like to see something along the lines of "If you lock it down you have to implement a kill switch. If a serious bug is found you implement a fix, and then you trip the kill switch. If you CAN'T implement a fix, then you trip the kill switch anyway! And unless the product is end-of-life, tripping the kill switch is a warranty failure". Although if the customer didn't apply the fix, you do get to charge them for the privilege of you doing it for them, and they get a "pay for" upgrade rather than a replacement piece of kit.
Let's take routers for example. How difficult would it be for - Netgear let's say - to sponsor an engineer to certify OpenWRT on their hardware. (That is, Netgear employs the engineer to say "Yes I've audited it". He's not personally liable for it.) Another couple of manufacturers chip in so they set up a compliance testing trade association - bear in mind that sort of organisation is not allowed to be choosy about membership. So the engineers are busy fixing and improving OpenWRT, and providing value to the association members in the form of certification! Not a member? No certification!
Basically, if you provide a product, you should be responsible for making sure that (a) it works as advertised, and (b) customers and bystanders are not hurt by it working as designed. Like in the automotive industry, you should not be held responsible for unauthorised modifications, but you are responsible for the safety of the product you supplied.
And this is what I meant about the dystopian Internet World of Things, where security etc is an afterthought, if it's even a thought at all. People get hurt by commercial products acting "as designed" (as in, design consists of just throwing components together, compatible or not who cares.)
Cheers,
Posted Sep 20, 2023 14:31 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
They need to nail down the language to avoid this kind of sheenigan while avoiding to hurt innocent bystanders.
And I don’t think anyone here is surprised that they suspect the Googles, Amazons and Microsofts, IBMs etc will attempt this kind of shell game.
Posted Sep 25, 2023 16:13 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
If your supplier goes bust, that's no excuse!
It's the same as all these companies supplying TVs with GPL'd firmware, but their suppliers didn't give them the software. The US may be rubbish at enforcing it, but in the EU it only takes a company to get dinged twice for repeatedly importing products they are unable to comply with the licence for, and the typical EU remedy would be "next time you import a product, you have to prove to Import that you have the software you need to comply with your obligations".
I gather they did manage to get that through in the US, but it would have been so much easier here - "repeat offender? You need to PROVE you're compliant before you can resume business".
Cheers,
Posted Sep 20, 2023 12:39 UTC (Wed)
by karim (subscriber, #114)
[Link]
++ on people pointing out that:
And, yes, this will likely weed out "cheap electronics sold on Amazon", but it'll also kill any startup playing in this space. But what does the EU know about having a vibrant startup ecosystem anyway? :P
Posted Sep 20, 2023 20:15 UTC (Wed)
by ringerc (subscriber, #3071)
[Link] (13 responses)
Hence the provisions about devs paid mainly by one company, ability to control which changes are accepted etc.
They want to stop HackMe.example.com from putting their product at arms length from legal obligations while retaining control, most commerical benefits and all the secret sauce kept in proprietary plugins.
This is a laudable goal.
Achieving it without too much byblast impact on other projects is the hard bit.
PostgreSQL for example is a genuinely independent open source project. EntrrpriseDB currently employs a significant proportion of the most active devs and committers and core team (steering group). But this has not always been the case and may cease to be the case in future. EDB doesn't control postgres and regularly fails to get changes it wants into the product because others don't see the wider value in them, don't think they meet PostgreSQL's high quality bar, or don't think they're worth the ongoing maintenance required. EDB benefits commercially from PostgreSQL and contributes to it. Where does that place the PostgreSQL product in terms of these requirements - and where should it?
It's reasonable to expect EDB to comply with these requirements as a software vendor. But it's not especially reasonable for them to transitively apply to the whole PostgreSQL project and all its other contributors just because there's a major commercial stakeholder. The overhead and administrative burden could easily fall on all contributors and impact the project as a whole. As well as being a discouraging drag on contribution it could give big stakeholders a greater lever for control over open source projects because they may become embedded in mandatory compliance processes imposed on the project to make releases or even accept changes.
I don't have any good answers here. It's a genuinely difficult balance and a blurry line. I don't want the "mycompany foundation" open core bait-and-switch-ware of the world to use this to evade what are some reasonable and justifiable expectations on quality and responsibility for the product. But I don't want to see that harm healthy projects with commerical contribution and co-operation either.
Posted Sep 20, 2023 21:09 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Exactly. And it's worth mentioning that "healthy projects with commercial contribution" encompasses single-developer projects that have accepted any sort of payment from an EU entity.
Posted Sep 20, 2023 21:39 UTC (Wed)
by kleptog (subscriber, #1183)
[Link] (10 responses)
Not a bad example actually. The obvious answer is that EnterpriseDB is responsible for what it sells. If there's a security issue that needs to be patched, EnterpriseDB can apply it to the version they ship. That they may not get the fix into the mainline PostgreSQL release is neither here nor there.
What responsibility does the PostgreSQL project have? Strictly speaking, none. But the people distributing PostgreSQL for money have a interest in working together with the project to make this work. In a sense this happens already, so I expect this law to formalise that process a bit more (if necessary).
> It's pretty clear that much of the ambiguity in the proposal is there to prevent companies from evading the law using faux-open-source "projects", open-core models etc.
One of the differences between US and EU regulation is that the US tends to formulate lots of precise rules, whereas EU regulation tends to be higher level leaving room for regulators to apply the intent of the regulation to specific examples. For example, the Italian regulators had banned subprime mortgages early despite there being no explicit rule against it, on the basis they looked like a bad idea. If people are expecting the CRA to provide detailed rules about who are or are not targetted they're going to be disappointed. That's not the way we roll.
If you're worried this might lead to selective enforcement, the flip side of this is that if a regulator targets a single open-source project, the fact they're not also going after every project with the same issues is actually a defence. So all you need to do is do a better job than the average commercial product (which isn't hard) and you've got nothing to worry about.
I think the discussions about this all being a huge amount of work for open-source projects is exaggerated. Nothing in the Act suggest things companies shouldn't be doing already. If you're deploying a product in 2023 without even doing the minimal cybersecurity checks, you ought to be shot. For a lot of open-source software there are standard Github CI/CD pipelines and bots which check for security issues. Tools like Coverity check lots of open source projects for free. I honestly think the average popular open-source project is in a much better state that most proprietary software and can trivially prove it too.
Posted Sep 21, 2023 2:37 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (9 responses)
Sure but there's a huge difference between "having to apply a patch", and "spend one month filling stupid paper form describing the possible impacts of the issue and its remediation". A bug needs to be fixed, period. No need to add bureaucracy to make the development halt after the first bug, and impossible to restart.
They could put the effort on the bug reporter for example: make it possible for a bug reporter whose bug report has been ignored to fill that form so that EU can ask the company if it really poses a security threat and why it's not fixed, and if the company doesn't respond in a few weeks/months, then deny it the right to sell the product in the EU until it responds. It would be more effective and limit the amount of bureaucracy inflicted on those who are already busy trying to fix the problem.
Posted Sep 21, 2023 11:47 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (8 responses)
And if your product has an actively exploited vulnerability that's causing actual damage, a simple email to a ENISA telling them about it and how to mitigate it is the absolute least you can do. You don't have to notify them for evey bug, that would be silly (and they'll probably tell you off if you do).
If the bug reporter includes a working exploit, it's worth notifying about ASAP. Otherwise, you can probably just fix it and move on.
Posted Sep 21, 2023 12:53 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
Every interaction I've had with the IRS in the USA has involved paper forms, which can either be sent by "certified international mail" (whatever local service turns into certified USPS mail in the USA - in my case, "International Tracked & Signed" from Royal Mail is the relevant service) or faxed. They will not accept e-mailed copies.
But my understanding of EU law is that EU governments can't do this - if they want paper copies of a form, they must be willing to print e-mailed versions out.
Posted Sep 25, 2023 16:20 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
I (as of this year) now have to fill in a tax return. Most European citizens don't - PAYE has removed that burden. I signed up for paper forms (web forms far too often are the work of the devil aka junior idiots who can't think straight and design things that are a nightmare / impossible to complete properly).
So, when my first return was due, I got an email telling me "You need to fill in the form online, we've scrapped paper". ARGGHHHH. I DON'T WANT ONLINE!!!
Cheers,
Posted Feb 13, 2024 17:40 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
IMHO in all ways the online reporting system is far preferable to the physical forms iff you can use it at all (not everyone can, e.g. people with large foreign shareholdings can't, but they probably have people to do their taxes for them anyway).
(And, of course, the UK's tax filing physical forms are massively better than the horrifying nightmare the US forces everyone to use.)
Posted Feb 13, 2024 19:47 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
I recently had to sign up to filing taxes. I said I wanted paper, and even before I got my first set of forms, I got a message saying I had to file online :-(
And my experience was they were demanding all sorts of information (that I filled in with 0s), but the banks etc are supposed to give them that information. It's a complete pain ...
Cheers,
Posted Sep 22, 2023 4:15 UTC (Fri)
by wtarreau (subscriber, #51152)
[Link] (3 responses)
Posted Sep 22, 2023 9:43 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
Writing a bot to inform them of each backported patch is entirely in-scope and acceptable - one e-mail per patch, and let the authorities handle it.
The only reason you might consider being a little less eager to send such mails is that by doing so, you've ensured that commercial downstreams are legally liable if they haven't applied that patch and their install of your software is compromised. On the other hand, this might be a desirable effect - it forces them to keep close to upstream, for fear of being found liable for something.
Posted Sep 25, 2023 2:36 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
Posted Sep 25, 2023 9:40 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Yes, and this is intentional on the part of the CRA; one of the concerns in making you legally liable is that you need some way to say "if you don't apply the fixes I have said are critical, then I'm not liable when your house of cards falls apart". And that's what the notification mechanism is; the idea is that if your users don't like you notifying them of a need to patch every day or so, they'll find a commercial arrangement with you that makes you less eager to notify the authorities of "required" patches.
If they don't shower you with enough money to make you behave the way they want (and take on the liability that comes with that), then as far as the EU's concerned, that's their problem to deal with, either by switching to a different source of software, or by getting used to taking all your patches, not just the ones with a CVE tag, or just accepting that they are responsible for checking all of your bugfixes for security relevance, and paying the price if they erroneously deem a bugfix "not security relevant".
One of the reasons we're seeing FUD around the CRA is that if you do decide that you're going to notify every commit as a potentially security-relevant fix (which you're entitled to do under the proposals so far), the free ride comes to an end for your downstreams; they have to either take all of your commits within a short time of you making them (which results in them having to change maintenance schedules etc to support such frequent updates), or they have to deal with liability for bugs you've fixed since they took a copy in the software you give them, or they have to persuade you to stop doing that (which will almost certainly involve giving you money).
Posted Sep 21, 2023 10:55 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
Actually a positive outcome would be to remove the need for open core bait-and-switch-ware. Because the people engaging in this could switch to just providing (paid) liability insurance, keeping the original FLOSS licensing.
Of course, very bad news for the freeloaders that want to consume FLOSS software without paying a dime to make sure someone will fix things in case of problem, the EU won’t let them freeload and hope someone else will fix things when needed.
Posted Sep 20, 2023 21:22 UTC (Wed)
by stybla (subscriber, #64681)
[Link]
Posted Sep 21, 2023 0:47 UTC (Thu)
by ch33zer (subscriber, #128505)
[Link] (7 responses)
Posted Sep 21, 2023 2:41 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (6 responses)
Also I don't see how they could draw a "perfect line" between commercial and non-commercial because this line does not exist. Sometimes some users of your code send you some money: this can change the perception of the relation, especially if you reach a point where you can make a living of it. And the vast majority of OSS that lives more than 3 years is backed by some companies who are able to pay some developers. This really risks to simply end a large number of projects because it will be considered that it's not worth the hassle of continuing to sell them, hence let's just stop developing them.
Posted Sep 21, 2023 9:39 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (5 responses)
A user giving you some money does not, in and of itself, make it a commercial setting. For it to be commercial, there needs to be an offer of product or services from you conditional on the receipt of money, followed by the money coming through. So, if you say "I'll fix this bug if people give me €10,000", and I send you €10,000, you're doing something commercial. If I see a "donate here" button on haproxy's website, and donate €10,000 because I love the project, it's not commercial - the money was a gift, and this applies even if I'm a heavy user of haproxy and also ask you to fix bugs.
Similarly, this is where the carve-out for projects where no single commercial entity has control is coming from; if Google and Facebook both pay developers on a project, but neither Google nor Facebook has overall control, it's out of scope. The only reason this isn't a more general "open source" carve-out is that we want to avoid the situation where Dodgy Products Ltd open-sources all of its code under AGPLv3 (making it "open source"), but refuses to accept outside contributions, and refuses to support any builds other than its own, but escapes liability because it's "open source". On the other hand, something like haproxy where no single company has control is out-of-scope as a project; it comes in scope if you're selling it (either on its own, or as part of a product).
Posted Sep 21, 2023 10:05 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (2 responses)
Posted Sep 22, 2023 21:27 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Actually, it is fairly black and white. Because it's basically the same calculation that needs to be done to determine if VAT is payable over the amount. If the €10,000 is paid for a patch, there's VAT payable and there must be an invoice. If the €10,000 is a donation there's no VAT. Since VAT is usually around 20% of the amount, there's a lot of case law and rules about these situations because it matters to the tax office. And in practice it's no-where near as grey as you think, because in every transaction the participants agree on the commerciality of the transaction as part of the agreement.
(Note: small businesses may be VAT exempt but that doesn't change the calculations. The invoice then just says "should have VAT but seller is exempt" and there's less paperwork.)
You can actually play around with this in some situations. Someone else made the argument that any organisation accepting money from the EU is commercial, but that all depends. If you get an EU grant for "improving the cybersecurity status of your project" that's non-specific so no VAT. If you get an EU grant for "making a secure and audited version of your project" that's a concrete deliverable and so VAT may be payable. The former wouldn't be commercial, the latter would be. The grant will include a statement clarifying which it is.
The US doesn't have VAT, so this probably sounds very weird to Americans. And possibly even to many Europeans who don't have experience with VAT administration.
Posted Sep 23, 2023 7:12 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
The US has Sales Tax, though, which is although it's a bit different is the same principle (we had the equivalent of Sales Tax before we joined the EU, hence all our "membership wholesaler"-type businesses). When we had Sales Tax, B2B transactions were exempt - VAT is similar in that you pay the taxman the difference between in and out - but B2C transactions were taxed. Likewise VAT is similar - the consumer can't reclaim the VAT.
So, assuming transactions come in three Sales Tax types, ie payable, exempt (eg B2B), and non-applicable, commerciality covers the first two but not the last.
(Membership wholesaler businesses were classed as B2B, but had a fair few B2C type members eg charities, people who used cards on personal businesses, sole traders and partnerships, etc etc, in order to avoid Sales Tax. Part of the reason behind VAT was to close that loophole.)
Cheers,
Posted Sep 21, 2023 12:44 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Does it matter if they approached you first?
Because in the F/OSS context, this "offer of product or services" is little more than "I can add that feature you asked for; it's going to take approximately $hours and I charge $rate." and if they agree, BAM, you're now an EU "manufacturer."
...And once you gain that lofty status, how do you shed yourself of it? I've not done any business with an EU entity in several years, though I'm still ostensibly "in business" in my home (non-EU) jurisdiction. In fact, earlier this week I was helping a gentleman from Germany gather the data I need to hunt down a bug, but no money is expected to change hands.
Posted Sep 21, 2023 13:06 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Who approaches whom doesn't matter. It's commercial if there's an offer of products or services, followed by an exchange of money; at that point, you're in a commercial transaction, and you are liable for the products or services you've sold.
And you only have that status for products and services sold in a commercial setting. Say I accept €10,000 from you to fix a bug in Linux kernel PPPoE support that affects your ISP; that fix is done as a service (the end product is a patch that applies to a known git tree from Linus). That patch is commercial - I offered to make the fix, you paid me for it. If I then do a later patch to Linux kernel PPPoE support to fix a different bug that affects me, or that adds a feature to kernel PPPoE support, that patch is non-commercial, because I didn't have a commercial relationship with you for that patch.
It gets trickier with a follow-on patch to the one you paid me for - if I supply a second patch that fixes a bug introduced by the patch you paid me for, that patch is considered part of the service you paid for (since it's a follow-up to our previous commercial relationship). But this is something a judge should be able to resolve; was my later patch a part of our existing commercial relationship, or was it a separate non-commercial transaction? A system update from Apple to your iPhone is probably part of the existing commercial relationship you have with Apple; a new app from Apple that's not forcibly installed probably isn't.
Posted Sep 21, 2023 7:58 UTC (Thu)
by gasche (subscriber, #74946)
[Link] (23 responses)
The open source communities are great potential allies for companies opposing the law: the public and the regulators will be more easily convinced by groups of volunteer contributors acting for the greater good than by the companies themselves. If I was a company or industry group trying to oppose the regulations, I would invest effort in convincing open source people that it is bad for them and encourage them to lobby against it in their own ways.
It may be that the regulation, in addition to going against the commercial interest of software sellers, is actually bad (in intent or in wording). It is certainly a reasonable idea to discuss it. But I think that we should acknowledge the risk of manipulation here and be fairly careful in our discussions, in particular:
The present article is falling way short in this respect. Does the author have previous experience dealing with how European regulations affect open source communities? We don't know. Did they get advice from FOSS groups that do so? We don't know. Was the article produced as a purely individual initiative, in the context of an existing open source project, or due to the concerns of a specific employer or sponsor? We don't know.
Note: I am not trying to suggest that there is anything nefarious hidden behind this article -- my best guess would be that it is overreacting a bit, but in good faith. I am just pointing that there *could* be, and that there are no mechanisms of transparency in place that would give us a chance of finding out if there was.
LWN is careful to provide transparency on travel sponsoring to avoid conflicts of interest. It should have done a better job here.
Posted Sep 21, 2023 18:08 UTC (Thu)
by corbet (editor, #1)
[Link] (3 responses)
Posted Sep 22, 2023 15:03 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (2 responses)
And on 1st reading, I agreed with the critic - especially after the comments of kleptog and franz, who seem to have some inside knowledge about the EU initiative.
Reading the parent comment a 2nd time, I can understand your interpretation that caused your reaction on a may-be accusation.
So, perhaps you could take it this way: Besides the author's report & opinion on the topic, some longtime LWN readers have commented here who seem to be involved in the process that created this regulation proposal. It might be of interest to present their take on it.
FWIW: I'm not involved in any EU initiatives. I'm the CEO of a German IT company that creates FOSS. IOW, I'm affected by that regulation and I'm interested in serious discussion about it.
Posted Sep 25, 2023 6:29 UTC (Mon)
by mrybczyn (subscriber, #81776)
[Link] (1 responses)
I'm also concerned by misinformation and lack of information on this subject. The article is based on my reading of the proposal and amendments, using only public sources (this is the general LWN policy). If you find any errors or omissions, please let me know. This is a complex matter, so they are possible.
For now, however, I can see nobody pointing out any factual errors in this discussion.
I think the CRA is too important to wait until all is set in stone. This is the reason for this writing. This is also why there are so many conditionals - the impact depends on standards yet to be written.
As probably everyone in the discussion, I have stakes in the outcome. I'm running a consulting business concentrated on embedded open-source security. My detailed bios are easy to find online.
And finally, if you want to discuss the subject more, there are various conferences with CFPs coming up. Submitting a panel is a possibility that could be really interesting.
Posted Sep 25, 2023 11:09 UTC (Mon)
by kleptog (subscriber, #1183)
[Link]
I think the EP committees and Council working parties are doing their level best to make this work and nobody is trying to kill open-source software. In fact, I feel both the Council and the Parliament went out of their way to clarify the impact on open-source projects and reduce work for small businesses. It doesn't help that much of the text is working who is responsible for a what, and what the powers and responsibilities of the Commission are, which means that it's somewhat vague on some details, because the point is they are worked out later. The EU doesn't generally write standards (it doesn't have the manpower), it adopts them from elsewhere which is why I think it's helpful for people to get ahead in thinking about how they'd like this to work and formalise it. Otherwise I fear we'll end up with Microsoft deploying an proprietary AI model on Github to determine the "security health" of projects, with no support if it produces strange results. We can do better.
Thanks again. I learned a lot from this article and ensuing discussion, and I hope others did too.
Posted Sep 22, 2023 22:14 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (18 responses)
I must say I agree with you. The Apple, Googles, Samsungs, Ciscos, Microsofts, etc of this world have a vested interest to make sure they bear no liability for any software issue in products they release. And they will likely have no problem publishing a lot of FUD about this proposal. We've seen this is previous proposals. I vividly remember when Reddit pushed a big post about the Copyright Directive, whipping up a frenzy, including links to old revisions of the act and complaining about issues that had long been amended out. The readers lapped it up and trying to fight misinformation in that thread was terribly depressing. There were legitimate issues to complain about, but they were snowed under by the misinformation.
So far I haven't seen a lot of noise on the CRA. I think companies are waiting a bit to see what the first round of amendments delivers.
But you are right that we as a community need to put serious thought how we want this to work. We are in a better position to come up with workable solutions and we should, because the status quo isn't working. If we can come up with a workable structure and implement it, then the regulators will fall in behind us. If we don't, we'll get something suboptimal imposed. People are working on this, but the discussion is important.
(I saw a comment about how I may have special inside knowledge about this Act. This is not so. I have however read a lot of EU legislation, including drafts and amendments. I've read the EU treaties and how they interact specifically with Dutch law and it's 4 levels of government and 3 supreme courts and those with each-other. How the EU legislative process works and discussing it friends who study this but don't care about IT. Helping a cooperative work through the evolving regulation of the energy market is an interesting experience. The EU is a complex machine, but it's interesting to watch how people across a massive diverse continent can come to a consensus (or not, as some topics show). But it also has many limits.)
With respect to your point about the the context behind the article, I think what I really missed was info about the author, it was my first comment. Newspapers often include a short bio of guest authors and I think it would have been helpful here. For pure technical articles it doesn't matter so much, but for these topics I think it does.
Posted Sep 23, 2023 0:04 UTC (Sat)
by pizza (subscriber, #46)
[Link] (17 responses)
Sure. But there need to be clear, consistent rules, with potential liabilities and compliance costs that are *proportionate to the income derived from that software*.
> If we can come up with a workable structure and implement it, then the regulators will fall in behind us.
...This seems wildly optimistic to the point of naivety.
Especially as no matter how you cut it, _anything_ other than "no warranty whatsoever" is going to result in mandated unpaid labor (lest they face potentially massive punitive penalities) from F/OSS authors that have nothing to do with how widely (or for what purpose) their software is deployed.
I don't care about the Googles, Apples, or whatnot. I don't even care about the Apaches, FSFs, or other F/OSS-focused organizations that already have lawyers and accountants on retainer. I care about the long tail of one-or-two-person projects whom about the only rational option is to just delete everything and close up shop.
Posted Sep 23, 2023 3:57 UTC (Sat)
by pizza (subscriber, #46)
[Link] (16 responses)
To put this in perspective, a basic general liability and E&O insurance policy has historically cost approximately 4x my average gross FOSS-related revenue. In a world where [as-currently-drafted-]CRA-style regulations are in place, those premiums will only go up, on top of the vastly increased costs of compliance (which is likely to eat up a significant portion of the already limited time I can put into F/OSS work to begin with!)
The options I see here are to [1] cease all commercial activity (ie shutter my side business) [2] jack my rates by at least 4x and effectively bring about #1, and/or [3] completely cease any independent F/OSS activities, by which I mean anything that could lead to liability falling onto me. Of course, there's also [4] roll the dice with potential financial ruin.
It's one thing to take a big risk if there's a realistic possibility of a big reward, but this is all risk and no reward. So #4 is out.
Posted Sep 23, 2023 16:06 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (15 responses)
If you're talking about E&O insurance, then it would appear you are delivering *services* in which case the CRA is not relevant to you (directly anyway). My impression is that the vast majority of people working in the open-community are delivering a service, namely, writing code for money. This makes sense, because the product itself can be downloaded for free. There are some exceptions, EnterpriseDB, Redhat, SUSE and Hashicorp come to mind.
I think you're putting too much stress on the liability part, since that's only really an issue if you're making promises about a product you're selling (assuming you're selling one) that leads to actual safety issues. The CRA is just the framework, which defines the terms under which a CE mark can be obtained. The actual details of what that means is not yet determined, and it will be a while before any possible certification becomes mandatory. Until then you can simply sell your product without CE marking and without warranty and you'll be fine. You might not be able to sell your product as part of some public procurement process, but I'm thinking that's not a goal for you.
The GP suggests I'm naive in thinking that the open-source community could get together and formulate the terms of what a "well-run security-conscious open-source project" looks like that the bigger projects could self-certify for. I hope I'm not because the alternative is someone like ANSI/ISO defining it and building a bureaucracy around it. Or worse, FAANG doing it. It's unfortunate, because I think we do, collectively, have a good idea what a "well-run security-conscious open-source project" looks like, we're just unwilling to write it down.
Posted Sep 23, 2023 17:52 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
Which is why, if you have a decent contract, you should hopefully be able to say "I am writing code at your request, you are responsible for making sure it does what's required". Then they are responsible for getting it certified and paying you to fix it if necessary.
Which is why, for projects of any size, I bang on about trade associations. A couple of developers get together, with a couple of clients each, form a trade association which says "for our members we will fix all known problems and certify them", and then all of a sudden we might have a decent financial basis for developers to make an income - selling certification. :-)
Cheers,
Posted Sep 23, 2023 21:05 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
Sure, and then they'll push back with a "ok, but just in case there's a problem, we want you to carry a $2 million liability policy" and when you inform them that this policy will cost more than the project budget, and you'll have to double your rate to cover the cost.
(This has happened to me, twice)
> Which is why, for projects of any size, I bang on about trade associations. A couple of developers get together, with a couple of clients each, form a trade association which says "for our members we will fix all known problems and certify them", and then all of a sudden we might have a decent financial basis for developers to make an income - selling certification. :-)
In other words, significantly increase the barrier to entry.
Posted Sep 23, 2023 21:17 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
But yes, I understand what you're getting at, as a sole trader this is going to be difficult (but if you've had that sort of conversation before, why will the CRA make any difference?).
Cheers,
Posted Sep 24, 2023 0:48 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
Because under the CRA, what used to be directly billable has been turned into general overhead that folks will expect me to provide as a matter of course.
If your operation is of sufficient scale then it's not going to be that big of a deal, but my "part time consulting/support services" operation is light years from that point.
Posted Sep 24, 2023 5:13 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
The benefits of F/OSS was recognized to the point that in the last few years, some developers saw their software land on Mars. It would not have been imagined 20 years ago that software developed by random people around the world could be critical to a space mission success. This is thanks to the commitment of these people on delivering as high quality code as possible without the fear of any liability nor anything else: 100% of their focus was on technical excellence. I'm afraid it might be the last time we see F/OSS software on another planet. what if the probe is hacked during it way due to an overflow bug on the deployed software and the mission ruined ? In practice any F/OSS developer would rather decline any request for help in getting their software better integrated because they won't know if that's going to expose them to a legal risk.
Posted Sep 23, 2023 20:52 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
(So this means RHEL is not covered by the CRA? After all, Red Hat is selling "Services", not "software?")
"directly anyway" pretty much is my entire point! By providing *services* associated with the software I also provide, I became a "manufacturer" and thus am on the hook for compliance, liability for security issues, noncompliance, etc. The "commercial activity" is the gating factor.
> I think you're putting too much stress on the liability part, since that's only really an issue if you're making promises about a product you're selling (assuming you're selling one) that leads to actual safety issues.
I use "liability" to refer to the penalties for noncompliance with the CRA -- this can be direct penalties (eg government/court-ordered fines) or indirect penalties (the "cost" of fixing issues that may arise, and/or the cost of being sued). These penalties/liabilites/etc are the kudgel that the CRA uses to achieve its goals.
And the CRA is intended to cover far more than "safety issues" -- Anything connected to the internet needs to be kept up-to-date for security issues that might result in ransomware attacks, data breaches, botnet/etc participation, and more. And sure, potential safety issues too, but there's not a lot of things that can be done with software running on a general-purpose computer that could lead to a physical safety threat.
Posted Sep 24, 2023 5:23 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
Which is another problem nowadays with few vendors providing long term support. Even if new software versions are provided, very often the user will experience some breakage, which is the very first cause why users don't apply updates. Many of us know the same with an old laptop having a nice combination of a properly tuned window manager, editor and various settings that we don't want to lose across an upgrade. I know people still using Windows XP because it just works and newer versions completely changed the way everything is organized and they don't understand it. Result: as long as XP works, let's not touch it. That's why I consider it important that most of the time the hardware dies before the software, especially for devices connected to the internet. And BTW we should avoid connecting devices that don't strictly require it. When I see the printer we have at work which sends requests to AWS for each button you press and that sends your scans there, it's unacceptable as it exposes the internal network to possible risks on these clients. And from a consumer perspective, who knows how long it will work, if the vendor can shut down the service when they want ?
Posted Sep 24, 2023 22:01 UTC (Sun)
by kleptog (subscriber, #1183)
[Link]
Possibly. What would you like the answer to this question to be and why? This is the sort of discussion we as a community should be having. Does it matter that the precise source code they're shipping is not available to non-customers?
Should Firefox/Chrome be held to a higher standard than OpenOffice or Gimp? How and why?
> By providing *services* associated with the software I also provide, I became a "manufacturer"
Sorry, I don't see this supported by any text, and it doesn't make any sense either. A manufacturer is someone that amongst other things, markets a product under a trademark they own. Whether you provide services associated with it is not relevant. What's really relevant here: the manufacturer is the person that can fix any problems.
> And the CRA is intended to cover far more than "safety issues"
Sure, this is confusing two things: when it comes to liability with respect to some (security) event, that's only relevant when talking about safety issues. The CRA covers many more things, but then you're only talking about non-conformity which is something else.
I guess the thing that surprises me most about this whole discussion is that I thought one of the big things about open-source is that people publishing/distributing code did so with a sense of "I made an effort to produce good code, as free of (security) bugs as I could manage". It seems that a sizable portion of the community doesn't feel this, or at least isn't willing to state it publically. That makes me sad, but I guess explains the dismal state of the software industry.
It's basically the "This is fine" meme, while the building burns down around you.
Posted Sep 23, 2023 20:58 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
I'd argue that creating these certification bureaucracies is one of the goals of the CRA. It doesn't matter if it's a "FOSS organization", or ISO or whatever, they're going to have to jump through whatever hoops the EU sets up to provide certifications (on an ongoing basis) which will of course require staff and ongoing funding.
Posted Sep 24, 2023 22:09 UTC (Sun)
by kleptog (subscriber, #1183)
[Link] (2 responses)
Posted Sep 25, 2023 16:58 UTC (Mon)
by ghodgkins (subscriber, #157257)
[Link] (1 responses)
You seem to have more knowledge about EU law than me, but from a plain reading of the current CRA text this seems at least slightly incorrect. Section 5, chapter 3 states that manufacturers must get external certification for "critical" class II products. Class II products are listed in Annex III; the category includes routers and CPUs along with several types of software: operating systems, hypervisors, container runtimes, public key infrastructure, and firewalls.
The question then becomes whether the product is "critical" - I believe that's a case-by-case decision made by a panel of bureaucrats. So it seems likely that the CRA will require third-party certification for at least some software, as well as the electronic devices it runs on.
Posted Sep 26, 2023 8:51 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
The computer/laptop you're using (if you didn't build it yourself) came with a CE mark. Many parts inside it also came with a CE mark. It's CE marks all the way down. The CE mark for the computer as a whole basically amounts to an assertion that the integrator checked all the components had a CE mark and that they were put together in accordance with the guidelines of those components. No third party checked whether they actually wired everything up correctly.
It's true that there maybe be components in there that had a third party audit (the WiFi chip?) but that's not something the builder of the computer needs to worry about. They just need to check the documentation of the chip and that they followed the guidelines.
It will be interesting to see which components in Annex III survive, the list was severly shortened by the Council.
> The question then becomes whether the product is "critical" - I believe that's a case-by-case decision made by a panel of bureaucrats
Hardly. The EU doesn't have the manpower and the regulators (all 27 of them) will be chronically underfunded, regulators always are. Bureaucrats are not your problem. The way this usually works is that whether a component is "critical" is agreed buy the buyer/seller when the contract is signed. The only time this will be checked is by a judge in the case of some liability suit. Then all the CE marks will be checked in the process of determining who is liable for what. If you think you can convince an uninvolved third party (aka a judge) you're not a critical product, you're good.
If a judge determines you are a critical product and you don't have the requisite audit, even the most underfunded regulator is going to see a chance for money. The idea behind all this is to try to configure the market to regulate itself via market forces, so governments can save money on the regulators themselves.
But you are right in a sense: many products will get third-party audits... by their customers doing due diligence on their suppliers. As long as you make clear agreements with your customers about who is responsible for what, you're set.
Posted Sep 25, 2023 8:11 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (2 responses)
I am not sure. Consider the original IJG libjpeg library. It has not has a single serious vulnerability in 25 years.
Posted Sep 25, 2023 9:45 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
THIS!!! IN SPADES!!!
Cheers,
Posted Sep 26, 2023 5:01 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Uhh... Whut?
There are some CVEs for it: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libjpeg
Looking deeper, it looks like nobody is actually using the original libjpeg, everyone seems to be using libjpeg-turbo. Debian even uses it to provide libjpeg, they seem to have switched some time in the previous decade.
So it looks more like the case of nobody really caring about it.
Posted Sep 24, 2023 6:55 UTC (Sun)
by riking (guest, #95706)
[Link]
Note that the Google policy that set the 90-day standard uses 7 days for "actively exploited vulnerabilities".
Posted Sep 26, 2023 2:37 UTC (Tue)
by mirabilos (subscriber, #84359)
[Link]
haha… (kudos to lynx for rendering those RSS links visibly)
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
[2] https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/...
The European Cyber Resilience Act
And hardware makers face zero liability as long as it's the end-user that installs the software.
The European Cyber Resilience Act
The European Cyber Resilience Act
And hardware makers face zero liability as long as it's the end-user that installs the software.
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
> Firstly, most software today is not designed. It's thrown together, it works, and that's that. Then it gets extended and extended and the parts don't work together. Etc etc.
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Placing on the market
Wol
Placing on the market
Placing on the market
Wol
Placing on the market
Placing on the market
Placing on the market
> So in other words, OpenWRT is not liable, the manufacturer of the equipment is not liable... which leaves you. But since you didn't "place this product on the market" you're not liable for any damage it causes either.
Wol
Placing on the market
Placing on the market
Wol
The European Cyber Resilience Act
- Companies will likely skip EU for first releases
- There will be companies whose business model will be CRA compliance
- Some OSS projects will like exclude EU
- This will further push centralization of services (SaaS)
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
> foundation" open core bait-and-switch-ware of the world to use this to evade what are some reasonable and justifiable
> expectations on quality and responsibility for the product.
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
The European Cyber Resilience Act
Wol
The European Cyber Resilience Act
The European Cyber Resilience Act
Risks of misinformation
- avoid FUD that creates uncertainty with no actual basis (it is easy to present regulations in a way that sound very scary for people without regulatory experience; is it actually an issue in practice?)
- be very transparent about who is participating to these discussion and what their own interests are
Nothing was disclosed with regard to this article because there was nothing to disclose; we have paid (OK, haven't paid the bill yet) for another article from a longtime LWN contributor, and that is all there is to it. It's kind of sad that you think we might be serving some other agenda.
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
#1 would mean making myself entirely dependent on $dayjob, but I've been laid off twice in the past five years, and that side business has meant I could continue to keep a roof over my family's head. That leaves #3 as the only rational choice.
Risks of misinformation
Risks of misinformation
Wol
Risks of misinformation
Risks of misinformation
Wol
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Risks of misinformation
Third-party certification
Third-party certification
Risks of misinformation
On the other hand, libwebp from 2011 has had tons of serious vulnerabilities.
Is it that Google programmers are incompetent and do not know how to write safe code ? Certainly not.
The fact is that security is not seen as a real priority even by "well-run security conscious open-source project"
and issuing updates to fix vulnerabilities instead of writing correct code from the start is seen as acceptable
if this allows for faster development or faster code, despite claims to the contrary.
Risks of misinformation
Wol
Risks of misinformation
The European Cyber Resilience Act
someone is using py3k… badly