True. And the "given enough eyeballs, all bugs are shallow" is a neat sounding thing from the past when the amount of code lines was not as much as now. Sometimes it is scary to see how long a vulnerability in the Linux kernel had been there for years, "waiting" to be exploited.

Yeah he didn't find the right unmaintained project. There are many many many cs undergrads starting projects that will become unmaintained pretty soon.

Debian actually started to collect and maintain packages of the most important rust crates. You can use that as a source for cargo

Which is why you shouldn't do that. Dependency nightmare is a real problem many developers face. More to the point they impose it on you as well if you are by any reason forced to use their software. Well established libraries are gateway to this. People are getting out of their way to complicate lives to themselves and massive amount of others just so they could avoid writing a function or two. Biggest absurdity I like to point out to people is the existence of is-number NPM package, which does that. It has 2300 dependent projects on it!!! Manifest file for said package is bigger than the source. And the author had the hubris to "release it under MIT". How can you claim copyright on num - num === 0?

On all the projects I manage I don't allow new dependencies unless they are absolutely needed and can't be easily re-implemented. And even then they'd have to be already in the Debian respository since it's a good and easy way to ensure quick fixes and patching should it be needed. Sometimes alternative to what we wanted to use already is in repo, then we implement using different approach. We only have few Python modules that are not available in repo.

Managing project complexity is a hard thing and dependencies especially have a nasty habit of creeping up. I might be too rigid or old-school or whatever you want to call it, but hey at least we didn't get our SSH keys stolen by NPM package.

THIS.

I do not get why people don't learn from Node/NPM: If your language has no exhaustive standard library the community ends up reinventing the wheel and each real world program has hundreds of dependencies (or thousands).

Instead of throwing new features at Rust the maintainers should focus on growing a trusted standard library and improve tooling, but that is less fun I assume.

It's a really wicked problem to be sure. There is work underway in a bunch of places around different approaches to this; take a look at SBoM (software bill-of-materials) and reproducible builds. Doesn't totally address the trust issue (the malicious xz releases had good gpg signatures from a trusted contributor), but makes it easier to spot binary tampering.

Do you really need to download new versions at every build? I thought it was common practice to use the oldest safe version of a dependency that offers the functionality you want. That way your project can run on less up to date systems.

Opensautists

100%.

In many ways, distributed open source software gives more social attack surfaces, because the system itself is designed to be distributed where a lot of people each handle a different responsibility. Almost every open source license includes an explicit disclaimer of a warranty, with some language that says something like this:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Well, bring together enough dependencies, and you'll see that certain widely distributed software packages depend on the trust of dozens, if not hundreds, of independent maintainers.

This particular xz vulnerability seems to have affected systemd and sshd, using what was a socially engineered attack on a weak point in the entire dependency chain. And this particular type of social engineering (maintainer burnout, looking for a volunteer to take over) seems to fit more directly into open source culture than closed source/corporate development culture.

In the closed source world, there might be fewer places to probe for a weak link (socially or technically), which makes certain types of attacks more difficult. In other words, it might truly be the case that closed source software is less vulnerable to certain types of attacks, even if detection/audit/mitigation of those types of attacks is harder for closed source.

It's a tradeoff, not a free lunch. I still generally trust open source stuff more, but let's not pretend it's literally better in every way.

It's about the complex rationalizations used to create excuses (pretexts).

The original is this:

Yeah but tbf it was deployed on mostly rolling release and beta releases.

No enterprise on prod is worried because they're still on RHEL 6 /s

OpenSSH backdoor

https://lemmy.ml/post/13801726

because AbstractTransactionAwarePersistenceManagerFactoryProxyBean needs to spin up 32 electron instances (one for each thread) to ensure scalability and robustness and then WelcomeSolutionStrategyExecutor needs to parse 300 megabytes of javascript to facilitate rendering the "welcome" screen