Meanwhile... [LWN.net]

Meanwhile...

Posted Apr 23, 2026 19:53 UTC (Thu) by GhePeU (subscriber, #56133)
Parent article: Dependency-cooldown discussions warm up

... a compromised Bitwarden CLI package was uploaded to npm and was live for a couple of hours: https://www.bleepingcomputer.com/news/security/bitwarden-...

Cooldowns or upload queues, it doesn't really matter what is chosen (though I personally like the latter better), but introducing even a 24-hour delay would truly help because in most cases either the maintainer or somebody else in the company/team will quickly notice an unplanned release.

to post comments

Meanwhile...

Posted Apr 24, 2026 10:08 UTC (Fri) by taladar (subscriber, #68407) [Link] (46 responses)

For the vast majority (in numbers) of packages that have a single maintainer who creates the package in their free time (not necessarily outside work but whenever they have time to work on it between the projects that are their actual main focus at work or between life events at home) they would not notice within a 24h period or even a 48h period since there is this little thing called weekends and also people are not generally in the habit of checking their own package releases constantly.

Meanwhile...

Posted Apr 24, 2026 12:42 UTC (Fri) by marcH (subscriber, #57642) [Link] (45 responses)

> they would not notice within a 24h period or even a 48h period since there is this little thing called weekends

Fine, make it 1 or 2 _work_ days. For vacations you should get coverage. If you are the only maintainer, then the project has "a bigger problem".

> and also people are not generally in the habit of checking their own package releases constantly.

Even if I'm very busy with other things and flooded with email as usual, I will 100% notice a "New X release!" notification if X is software I maintain! It's a rare and important enough event. If it's too routine, then something is probably wrong with X's release lifecycle (which is obviously a very important parameter in this entire discussion).

Projects with bigger problems

Posted Apr 24, 2026 14:22 UTC (Fri) by farnz (subscriber, #17727) [Link] (44 responses)

Part of the reason that these "supply chain" discussions end up in a mess is that there's at least three groups of projects out there:

Sole maintainer projects, done in spare time, low volume of users who'll care about a supply chain attack.
Sole maintainer projects, done in spare time, taken as a dependency by a big user who'll care about a supply chain attack.
Group maintained projects.

There's a reasonable fear that everyone's focused on the group maintained projects, where vacation cover etc is a sensible requirement, and not thinking about what the rules do to someone who thought they were in the "low volume of user" category, but in fact is in the "sole maintainer, taken as a dependency by a big user" category. And we have had examples over the years (libxml is the most recent I recall) where there are projects that are being maintained by a sole, dedicated and hardworking, maintainer, who needs to take a break for a bit, but is worried about what will happen to their big users if everything blows up while the maintainer takes 72 hours away from connectivity.

If you're on a 72 hour break from civilization (e.g. at a family event and not checking notifications daily), you won't notice a "New X release!" of something you maintain - you're not reading e-mail, so you won't see it. If your big users are depending on you seeing that and taking action within 48 hours of a new release, then there's an expectations gap. And it's much worse if you didn't know you had big users with such expectations - everything blows up because you thought it was just a few people playing with it for fun, but BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Projects with bigger problems

Posted Apr 24, 2026 17:05 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

Agree one size does not fit all. Which is why cooldowns, timers, queue lengths and what else should be configurable. What matters at a macro level is the approach and high level architecture, not the low-level parameters.

> BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Every time Big pro relies on a poor, burn out and single maintainer, they have only themselves to blame. If you need better, pay up. It really is that simple. Business is all about trust relationships and managing risks and this just one of them - among many other "suppliers". Business as usual, moving on.

Projects with bigger problems

Posted Apr 24, 2026 17:32 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

Right, but the high level approach we're discussing is "put a delay between maintainer publishing a new release and it being generally used, rely on the maintainer to take action if a release is bad to protect the users".

For group maintained projects, this is fine - one or more of the maintainers will be around to handle the notification that the release is bad, and will take action, But for sole maintainers, this runs into the "what if the maintainer is absent at no notice" problem; given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

One answer is social change - we accept that BigCorps will effectively take over sole maintainer projects by adding more maintainers, and if the sole maintainer doesn't want that, BigCorp will fork it and group maintain their fork, trying to stay in sync. This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

Projects with bigger problems

Posted Apr 24, 2026 17:52 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

> given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

If the sole maintainer "logs off forever" (or a very long time), then there is a much "bigger problem": the project is just orphaned which means any discussion in release delays or other lifecycle questions is pointless.

> This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

I miss what there is to "accept" or "not accept" here... The ability to fork is intrinsic to software freedom. As is the freedom to pick the fork you prefer. Forking is pretty much the essence of free software and it happens frequently, that's just the way things are. BTW "hostile" is a very binary: forking has many shades of grey.

BTW any decent BigCorp has internal mirrors of most of their dependencies (to avoid outages if nothing else) and how they update those is effectively implementing "private cooldowns" already. The richest ones implement all sorts of human and/or automated reviews and inspections on updates already (which other "cooldowns" can happily rely on, as already noted in the main article)

These internal mirrors often have extra commits too, which may or may not be submitted upstream. So I guess you could already call them "forks" depending on some artificial set and personal thresholds.

Maybe they should provide their reviews to the world

Posted Apr 25, 2026 2:41 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

cargo vet and cargo crev already exist

Projects with bigger problems

Posted Apr 27, 2026 9:18 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

What's needed is people to stop complaining when companies work in their internal forks first - all these devices shipped with a fork of the Linux kernel, for example, are doing the right thing from a supply chain security perspective, and you should expect them to have private patches that never get upstreamed.

Projects with bigger problems

Posted Apr 27, 2026 13:04 UTC (Mon) by Wol (subscriber, #4433) [Link]

> What's needed is people to stop complaining when companies work in their internal forks first

Isn't this what MOST people do, including FLOSS devs, work on an internal fork first?

The minimum required (and also maximum necessary) aka "necessary and sufficient" for companies to be considered "good FLOSS citizens", should be that their production repository (or a copy thereof) is world-readable.

If they want to make the effort to upstream their fixes (they should, it's in their interest, but it's their decision), then that's down to them.

And if the FLOSS developer wants to plunder their repository for good ideas and/or code, that's down to them!

Once we get over the current "OMG AI is finding exploits" scare, I would hope that the EU CRA encourages this to become the norm. Much less effort than doing stuff in-house.

Cheers,
Wol

Projects with bigger problems

Posted Apr 24, 2026 18:37 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (37 responses)

At the bottom, it's a huge free rider problem. There should never be a piece of critical infrastructure that everyone depends on that's supported by a single hardworking maintainer. Everyone who depends on that critical project needs to step up and provide some support, whether it's dedicating some of their developer time or just chipping in some money so the maintainer can afford to hire help. Much more than technical solutions, we need a change in people's expectation that they can freeload endlessly off other people's hard work.

Projects with bigger problems

Posted Apr 24, 2026 19:08 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> we need a change in people's expectation that they can freeload endlessly off other people's hard work.

"endlessly freeloading" is a *feature*, and IMO is the primary reason why F/OSS has been adopted so widely.

Projects with bigger problems

Posted Apr 24, 2026 19:58 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

And now people are discovering that zero cost comes with some downsides as well as upsides. If you want guaranteed rapid response to security problems, you're going to pay for it one way or another. In practice, chipping in to support the projects you depend on- whether that's direct financial contribution or paying for some developer time devoted to dependencies rather than your project- is still going to be way cheaper than paying for a proprietary solution.

Projects with bigger problems

Posted Apr 24, 2026 20:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (34 responses)

> At the bottom, it's a huge free rider problem [...] There should never be... Everyone who ... needs to ... [...] We need a change in people's expectation [...]

Unless you live in a dictatorship (and even then...) there is no "People should just..." Social pressure has never worked beyond tribe-sized groups. People just try things, that's human nature at its core. Some people take big risks (like: depending on an orphaned project), others not. Some succeed, others not. Some learn (e.g: when hacked), others not. Some do as taught, others not. Some care, many not. Trying to stem that tide never got anywhere.

The only two effective actions are:

- Making things illegal. Vaguely effective sometimes. For instance: changing a software licence.
- Offering an alternative that people like better. For instance: DRM-protected streaming that Just Works over free P2P downloads of semi-random and possibly infected media.

In the past you could "educate" and influence a little bit but that's pretty much dead nowadays in this era of attention merchants and echo chambers. You can still publish stuff but that's more for personal "I told you so!" visibility and gain than for actual prevention.

Projects with bigger problems

Posted Apr 27, 2026 17:08 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (33 responses)

That's fair. Maybe a better way of making my point is to say that there's a free rider problem, and we will continue to suffer from all the knock-on effects of that free rider problem until there's some kind of solution. IMO, one part of the solution- probably the easiest part to deal with- is technical. Right now, even someone who would love to contribute to supporting all their upstream dependencies (including dependencies of dependencies to the Nth order) can't easily do it. That seems like something that could be fixed.

I'm imagining a FOSS forge that includes some kind of contribution system. Downstream projects register, and the forge can figure out what their dependencies are by looking at their code. Then they can sign up to donate, with a one-time or recurring contribution. The forge takes a little off the top to support its infrastructure and distributes the rest to whichever dependencies have registered to receive contributions. The trick is that any project that signs up to receive contributions has to agree to pass some of the money they receive upstream to their own dependencies, so indirect dependencies don't get left out. A project that doesn't want to receive contributions- maybe they decide the amount of money isn't worth the tax hassle- can decline them or just increase their pass-through to 100% so all the money gets sent to their dependencies. Any project that wants to receive contributions has an incentive to join the forge rather than some alternative, which should help build momentum for the idea. It's a purely technical solution, but at least it provides the infrastructure to make financial support for projects feasible.

Projects with bigger problems

Posted Apr 27, 2026 19:17 UTC (Mon) by marcH (subscriber, #57642) [Link] (32 responses)

Something like https://support.deezer.com/hc/en-gb/articles/360002471277... but for software - I like it!

GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in? As mentioned at this reference. As soon as there is money, there is an order magnitude more people trying to cheat or game the system. But still worth a try.

Projects with bigger problems

Posted Apr 27, 2026 20:53 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

> Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in?

It's going to make us yearn for the good ol' days of "bug bounty" slop.

Projects with bigger problems

Posted Apr 27, 2026 21:25 UTC (Mon) by marcH (subscriber, #57642) [Link] (6 responses)

> > GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

> Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned. As open-source usually does - including open-source "forges". Cause you can't really patent pure ideas yet (knock on wood) despite monopolies trying hard. Code may be flowing only one way, but you can't stop ideas from flowing in all directions.

Projects with bigger problems

Posted Apr 27, 2026 21:47 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned.

... so you want them to take a[n ever-increasing] cut of money paid to F/OSS developers, instead of "just" advertising, datamining, and actively undercutting our professions?

The only "lesson" here is that these for-profit organizations do not, have never, and never will, have our backs. They view us as (a) a market to be captured and locked in, and (b) an expense to be minimized, if not eliminated entirely.

Projects with bigger problems

Posted Apr 27, 2026 22:42 UTC (Mon) by marcH (subscriber, #57642) [Link] (4 responses)

I'm aware this is a lost cause because antisocial media has been methodically destroying any sort of nuance or subtlety but.. the world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Projects with bigger problems

Posted Apr 27, 2026 23:21 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> The world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Sure, that's fine.

What I take issue with here is that this gives the big forge[s] another lever to use to lock folks in. Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

The only way I see this working is a through a truly neutral private collection society with a "public good" charter or a governmental department. And even then I don't see why the overwhelming majority of freeloaders would ever _voluntarily_ pay in.

Projects with bigger problems

Posted Apr 28, 2026 12:13 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)

> Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

I agree there would be significant network effects but I don't think they would be as bad as for music for instance. If only a few artists you like are missing from your favorite streaming service, then you're unlikely to subscribe to an extra one just for those. I bet most people just _buy_ that particular music instead of streaming it in that case. Whereas with a voluntary donation system, you can split your donations anyway you like any time you want. It seems quite different from that perspective.

Also, artists are getting ripped off because there is yet another indirection layer / middlemen: record labels. Not sure why these are still dominant in our Internet age (getting off-topic) but there's no rip-off equivalent for FOSS and I don't see why there would be any there.

Projects with bigger problems

Posted May 1, 2026 9:16 UTC (Fri) by massimiliano (subscriber, #3048) [Link] (1 responses)

IIRC, the Radicle (https://radicle.xyz) project was attempting to build a "trickle" system to transfer funds from projects to dependencies.

It was all blockchain-based, so it would not give power to monopolies.

I do not know what happened to it...

Projects with bigger problems

Posted May 1, 2026 9:50 UTC (Fri) by liw (subscriber, #6379) [Link]

I believe you mean Drips, drips.network.

Projects with bigger problems

Posted Apr 27, 2026 22:07 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (23 responses)

How do you stop the equivalent of bots listening to fake music and cashing in?

Because there's no money in that case. There isn't some big pot of ad money that gets shared between projects depending on how many other projects depend on them. Any money that comes in is associated with the project that's willing to give it, and that money goes to the project's dependency tree. A project can only bring in money if and to the extent that other projects willing to give money actually use it as a dependency.

The one way I can see to game the system is that as I described it, the money a project sends to its dependencies is divided equally rather than based on some measure of their relative importance. That gives programmers an incentive to game the system by multiplying dependencies. For example, if I have a project with only one dependency, all my pass-through money goes to that one project. Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project. Even then, my project has to do something good enough to get people to depend on it in order to bring in any money.

Projects with bigger problems

Posted Apr 28, 2026 9:19 UTC (Tue) by farnz (subscriber, #17727) [Link] (22 responses)

The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library. The result is that my "EasyCryptography" library has no dependencies not owned by me, and I get all the money, instead of my fair share.

Projects with bigger problems

Posted Apr 28, 2026 12:03 UTC (Tue) by marcH (subscriber, #57642) [Link] (5 responses)

> > Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project

Rewards lines of code instead of each project equally? You could still game that but it would pretty obvious and look really bad.

With good test coverage tooling you could even reward lines of code actually used, excluding optional features.

> I vendor it and make some licensing compliant changes to make it "my" library.

That one looks pretty easy to detect automatically TBH. If not automatically, at least very obvious to humans.

Projects with bigger problems

Posted Apr 28, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Code obfuscation techniques have been a thing for a long time, and are something LLMs are good at (while introducing new bugs, of course).

That makes detecting that "EasyCrypto" is in fact a wrapper around OpenSSL, and not a bunch of carefully written new cryptography code hard - because the obfuscation stops it being obvious. And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

Projects with bigger problems

Posted Apr 28, 2026 14:08 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

But a project must have users in the first place to have any gain.

> And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

This assumes there will be a significant number of users for long enough with NONE noticing anything weird. And no AI check noticing anything either. It's not impossible of course but that seems a bit of stretch. Definitely not "routine" enough to threaten the model as a whole.

Projects with bigger problems

Posted Apr 28, 2026 14:55 UTC (Tue) by farnz (subscriber, #17727) [Link]

If it were genuinely uncommon, then we wouldn't be seeing issues with the supply chain to begin with - people would be noticing weird, and not using it.

The whole reason we're having this discussion is that people motivated by financial gain are attacking F/OSS software sources with the intention of clearing off with their ill-gotten gains - this is just an extra money path for them to take.

Projects with bigger problems

Posted Apr 30, 2026 10:39 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We really don't want to encourage projects using more lines of code and more verbose programming languages.

Projects with bigger problems

Posted Apr 30, 2026 13:29 UTC (Thu) by marcH (subscriber, #57642) [Link]

Right, splitting across dependencies is not easy. Maybe it could simply be up to each project to value each of their own dependencies. They would be "politics" of course but projects should have the best knowledge. Also, "politics" is not always a bad word: an endangered dependency really difficult to substitute or re-implement could be valued more for no real "technical" reason and that would be OK.

Projects with bigger problems

Posted Apr 28, 2026 17:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library.

And why would anyone buy your library, when OpenSSL is available?

Projects with bigger problems

Posted Apr 29, 2026 7:42 UTC (Wed) by farnz (subscriber, #17727) [Link] (14 responses)

My library is designed to be much easier to use for common tasks than OpenSSL, at the expense of removing all the power that OpenSSL exposes. In an honest world, it's a wrapper around OpenSSL to make it much easier to use; in this dishonest world, it pretends to be a simpler SSL library (and probably even points you at OpenSSL if you need the full power it exposes).

Projects with bigger problems

Posted Apr 29, 2026 16:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

So, like Boring SSL?

Your library will need to add some additional functionality for people to prefer it to raw OpenSSL, especially in the LLM age.

Projects with bigger problems

Posted Apr 30, 2026 10:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (11 responses)

Sure - but if I can find such a niche, I can game the system to get all the money, rather than just the share I earn by providing a nice wrapper.

Projects with bigger problems

Posted Apr 30, 2026 13:31 UTC (Thu) by marcH (subscriber, #57642) [Link] (10 responses)

If a system can be gamed only in rare niches, then it's a pretty good system. It means "manual" policing is minimal and doable.

Projects with bigger problems

Posted Apr 30, 2026 13:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (9 responses)

Quite the opposite - you'll have the spam problem, which means that manual policing is not doable (since you're flooded by possible attacks), along with attackers going for every niche they can with libraries that have everything they depend upon vendored instead of credited, so that they can get the full payment, rather than letting the people they depend upon get some income.

Projects with bigger problems

Posted Apr 30, 2026 14:34 UTC (Thu) by marcH (subscriber, #57642) [Link] (8 responses)

For money to be there you need users to give some and I still didn't get how you get a significant number of users with your scheme, sorry.

Projects with bigger problems

Posted Apr 30, 2026 14:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (7 responses)

You just need to flood out the catalog with so many projects in each area of application that, while any single project doesn't get much money, anyone trying to find something useful in there is likely to pick up one of your projects, and not one that's honest.

This is also a problem in retail - if you search eBay, AliExpress, Amazon or other marketplace sites for something fairly generic (as opposed to something that has active trademark protection), you're quite likely to be overwhelmed by large numbers of apparently identical versions from lots of random companies that you don't recognise.

Projects with bigger problems

Posted Apr 30, 2026 17:33 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Projects with bigger problems

Posted Apr 30, 2026 17:37 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

I see it all the time - you want a HTTPS client, or a WiFi manager, and unless you know the name of the project you want already, you search for a generic term like that. And those terms will be absolutely overloaded with automated spam options - unless you know already that cURL is your HTTPS client of choice, or that you want IWD to manage WiFi connections, you're going to be facing people flooding out the things you want.

Not to mention typosquatting and other attacks on the humans doing this - you think you're donating to cURL, but you're donating to cURI instead.

Projects with bigger problems

Posted Apr 30, 2026 17:46 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

When people are overloaded with generic offers, they usually turn to stats, reviews and other reputation systems and for software that is more than enough, you just need to invest more than a few minutes.

I think you also keep losing sight that we are discussing _voluntary_ contributions to... projects randomly picked up in a list? I'm not saying this would never happen, I'm just saying it will be small enough not to harm the system as a whole. Same for typosquatting.

For a bad actor typosquatting, security and owning target systems is probably more valuable than collecting contribution pennies.

Projects with bigger problems

Posted Apr 30, 2026 18:02 UTC (Thu) by farnz (subscriber, #17727) [Link]

Right, and what I'm saying is that the system will not work, because as soon as there's money in the system, people will game stats, reviews, reputation systems, and more.

As a result, either you have no contributions (hence no money, hence no attackers), or you're faced with a flood of attackers making the system more expensive to run. The only reason Temu and places like it survive is that, with a flood of attackers, you still have people who have to pay to get the goods at all; but if I don't have to pay, why would I risk paying on a platform that's full of scams?

Projects with bigger problems

Posted Apr 30, 2026 17:42 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Even if there is only one module in the entire namespace that implements $functionality, how exactly are random software developers supposed to know what its name is without first searching for "$language module for $functionality" ?

Projects with bigger problems

Posted Apr 30, 2026 17:54 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

I meant no one looking for software is going to think "Oh, I can choose between 50 'generic' options for this, I'm spoiled with choice, this is great! Lucky me".

Software being all fixed costs and network effects, when you see 50 different options you immediately know that at least 47 are garbage if not more. Once you have 3 viable left, you are still depressed because now you need even more time to evaluate the 3 left, as you know dependencies are really hard to change and picking up one is pretty long-term commitment.

This is pretty much the opposite of buying "generic" stuff on Temu.

Projects with bigger problems

Posted Apr 30, 2026 17:59 UTC (Thu) by farnz (subscriber, #17727) [Link]

No, they're going to think "oh, this platform is awful - it's got 5,000 options, and I can't see how I find the legitimate ones in all the junk, so I'm not going to donate to anything on this platform at all". And thus, the platform ends up dead.

Projects with bigger problems

Posted Apr 30, 2026 11:08 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

seesms to have some good value then!

Meanwhile...

Posted Apr 25, 2026 2:06 UTC (Sat) by roc (subscriber, #30627) [Link] (2 responses)

> but introducing even a 24-hour delay would truly help

Unfortunately we are now in a world where 24 hours is more than enough time for AI to reverse engineer bugs, develop exploits and deploy them.

Meanwhile...

Posted Apr 27, 2026 16:22 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Note, though, that the original motivation for the delays was specifically about supply chain attacks, meaning deliberately introduced backdoors. The attacker in a supply chain attack doesn't need any time to figure out how to exploit it; if they need to wait any time it's for people to install the software so they have some targets. Deliberately introducing a delay is there to give the defenders, and the defenders' LLM, time to detect the backdoor before the attacker has a chance to exploit it.

Meanwhile...

Posted Apr 28, 2026 10:23 UTC (Tue) by taladar (subscriber, #68407) [Link]

That is not really true for general supply chain attacks though. Only very targeted attacks need no time on the attacker's side. Broadly distributed ones still need the attacker to discover who actually used the code they backdoored and which of those targets are worth attacking further.

Meanwhile the comment you replied to is probably about all the security fixes whose rollout would also get delayed with this.