That is a genuinely good strategy.

Pretty much with anything ya.

Unless there's some super important thing I need in the latest release, if my shit works and there's no security vulnerability, im in no rush to update.

I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It's an incredibly robust standard library that virtually guarantees I won't need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.

And since javascript libraries tend to be so small and focused

Lol, LMAO even

As much as some people deride it Javascript is one of the most used languages on the planet.

This is basically the same as people thinking windows is less secure because it's more often targeted.

JavaScript does have a bit of a problem with dependencies but it isn't much different than other languages with built in package managers like rust. It's just a bigger juicer target.

That sounds more like bad practices from the community. It definitely has ways to use exact versions. Not the least of which the lock file. Or the shrinkwrap file which public packages should be using.

Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.

The good news is that there already is a gold standard for supply chain security: the Go programming language.

Lmfao

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

17%!

Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can't imagine about the long tail which receives less attention).

Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.

In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.

EDIT: Also, I just noticed that he called it a "recent" analysis. It's roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.

That article has lots of issues:

17% of the most popular Rust packages contain code that virtually nobody knows what it does

That's not true at all, the article where he got that information from says:

Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

He then lists some ways packages can be maliciously compromised:

1. Steal credentials and impersonate a dev
2. Misleading package names
3. Malicious macros (this one is interesting, had never considered it before)
4. Malicious build script

And his solutions are:

1. Bigger std library (solves none of the above)
2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn't match the source and is detectable)
3. Decentralized packages (which worsens every security concern)
4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

Honestly I can't take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn't propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.

Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this

But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?

I'm guessing things were working out pretty alright, even with the insane amount of dependencies per project. The awareness and the increasing frequency of supply chain attacks is relatively recent for npm. But who knows, maybe the tech giants in control of the web standards are happy to keep using their own vendored registries.

If you're asking why there isn't one shipped with JS, the answer is because JS is built for the web, and the "don't break the web" rule makes changing things in JS hard, as well as browser devs pushing back hard on anything that increases install size.

If you're asking why as a community, we haven't agreed on a single package to be a stdlib - lodash.

Apt is great, but it does not work with every language. As an example, you cannot use apt with maven (java) AFAIK.

I know this is a joke but im old enough we used to install the os and had it on the network and eventually update it but then it got to the point were like being connected to the internet for like a minute and the machines were compromised. Thats when we got off our duffs and started making custom installs that had updates and configurations and software pre installed before we even connected it to the net.

And how would apt help in this particular case? A supply chain attack can happen with any particular package manager. In this case, the compromised package was detected and mitigated within 93 minutes, affecting a total of ~330 users. Which is a lot better than how a lot of distros handled the xz breach last year.

All reasonably secure package managers (and https) operate on a chain of trust. There is little that can be done if that chain of trust is broken.

Based on this the cause was a malicious VSCode extension that stole credentials that were later used to trigger a deployment CI/CD pipeline. If there's anything to learn from this, it's probably to not use VSCode.

I need to build it, jellyfin-tizen is a separate project for Samsung TVs

Because they could be changed or have something sneak in the library?