Ugh, another avenue for emotional blackmail...

Posted Jun 5, 2025 22:49 UTC (Thu) by Wol (subscriber, #4433)
In reply to: Ugh, another avenue for emotional blackmail... by pizza
Parent article: Open source and the Cyber Resilience Act

> (I also wonder how exactly this is supposed to work with modern software ecosystems that routinely require directly pulling in dozens, if not hundreds, of relatively small dependencies....)

The article tells you, the law tells you ...

IF YOU'RE NOT *SELLING* IT, YOU'RE NOT LIABLE !!!

If you don't want to touch it with a ten foot barge pole, just don't sign a contract! No contract, no liability. End Of.

If you're routinely pulling tens or hundreds of dependencies, but haven't audited them, that's called negligence. Doesn't matter whether you're a tin-pot lone developer, or a mega-billion company.

What the CRA will do is turn those negligent projects into "here be dragons" zones. Yes it'll have the unfortunate side effect of effectively killing off many of them. But at the end of the day, do we really need 50 different open-source implementations of the same two-line utility that effectively just changes the variable names in the source?

And if it results in a bunch of Open Soruce Co-Operatives providing support and CE markings for those utilities, then that will put food on the tables of Open Source guys. So yes, I would, most certainly, be only too happy to touch this with a punt pole :-)

Cheers,
Wol

Ugh, another avenue for emotional blackmail...

Posted Jun 6, 2025 7:22 UTC (Fri) by taladar (subscriber, #68407) [Link] (5 responses)

> If you're routinely pulling tens or hundreds of dependencies, but haven't audited them, that's called negligence. Doesn't matter whether you're a tin-pot lone developer, or a mega-billion company.

Counterpoint, if you are overly focused on the number of dependencies you are in denial about the fact that large dependencies have areas that bit-rot just as much and are just as unmaintained, just without a convenient way to talk about them individually and without an easy way to see when it was last updated. And, for that matter, without a convenient unit to audit one at a time and judge how much the current version diverges from the last one you (or someone you trust) audited.

And if you think you can just avoid using a dependency altogether and implement it yourself then you are in denial about the fact that the same is true about your own code. Code isn't inherently better because it was written by your own past self and bit-rots in your own code base compared to a dependency. In fact, what essentially amounts to an internal dependency with a single user is very likely less reviewed and audited and has more undiscovered bugs, than an external dependency used by many people.

Ugh, another avenue for emotional blackmail...

Posted Jun 6, 2025 9:20 UTC (Fri) by dottedmag (subscriber, #18590) [Link]

Actually I have done a project of dependency trimming on a medium-sized project (300 kLoC) in the past. The project shed about 99% of its dependencies counting by LoC and about 60% of dependencies counting by the number of dependencies.

The end result was _shorter_ code: turned out implementing just the required subset of the functionality in-tree was easier than adapting to variegated conventions of dozens of upstreams.

At the end only the hard stuff remained as dependencies: cryptography, complicated algorithms and data structures, parsers.

Ugh, another avenue for emotional blackmail...

Posted Jun 6, 2025 11:54 UTC (Fri) by pizza (subscriber, #46) [Link]

> And if you think you can just avoid using a dependency altogether and implement it yourself then you are in denial about the fact that the same is true about your own code.

You have left out the fixed per-dependency/audit overhead.

One set of paperwork is a lot less work to manage, maintain, and update than several dozen (or an order of magnitude more).

> Code isn't inherently better because it was written by your own past self and bit-rots in your own code base compared to a dependency.

One key difference is that once audited, it's done, and it won't change out from underneath you and require a new audit. And it can also be part of of the same audit (and paperwork) as your main body of code.

Ugh, another avenue for emotional blackmail...

Posted Jun 6, 2025 15:00 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (2 responses)

> Counterpoint, if you are overly focused on the number of dependencies you are in denial about the fact that large dependencies have areas that bit-rot just as much and are just as unmaintained,

> And if you think you can just avoid using a dependency altogether and implement it yourself then you are in denial about the fact that the same is true about your own code.

That’s not the point. Delegation reduces accountability. Reduced accountability reduces quality. That’s true in all domains not just IT, that’s why tenders for big projects forbid subcontracting bellow a certain level (usually, after painful failures).

And you can fail with one level of subcontracting just like you can fail with a handful of dependencies, and you can succeed with 10 levels of subcontracting just like you can succeed with hundreds of dependencies. However on average, all other things being equal, and humans being human and prone to pass the shit-can, you’re almost certain to be in deep trouble if you abuse the delegation amount.

Big dependencies versus many dependencies

Posted Jun 6, 2025 16:54 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

The problem is that what looks from the outside like "one big dependency" is often internally "100 small dependencies sharing a repo and a single point of contact", with worse accountability issues than if it actually were 100 small dependencies, since you have the "everyone thinks somebody else is responsible for that module, but nobody will take responsibility".

As a result, "all other things" are not equal; the larger a dependency is, the more likely it is to be hiding subcontracting from you, with the resulting pain around too many layers of subcontracting.

There's an irreducible complexity here; each component part of the system needs maintaining. If you have 100 small dependencies, each of which contains one component part, then you have 100 relationships to maintain. If you have 10 bigger dependencies, then you see 10 relationships to maintain, but those 10 may well be simply managing 10 relationships themselves (and not maintaining anything), leaving you dependent on 110 relationships going well (the 10 you maintain, plus the 100 hidden sub-contractors).

If you're aware that this is what's happening, that can work better than directly managing 100 relationships; if you believe that you're reliant on 10 relationships, but there's actually 100 hidden relationships, that's where things can go horrifically wrong (since the 10 you think you're reliant on have reasons to lie about the relationships they're maintaining with their sub-contractors, in order to keep you happy).

Big dependencies versus many dependencies

Posted Jun 10, 2025 7:47 UTC (Tue) by taladar (subscriber, #68407) [Link]

And to add to that, getting other people to do something tends to always be harder the more levels of indirection there are so good luck getting one of those big dependencies to maintain their internal relationships to the level you prefer.