Sure there are packages trying to solve 'the world' and as a result come with a whole lot of dependencies, but isn't that on whoever installs it to check?
My point was that git clone of the source can't be the solution, or you own all the code... And you can't. You always depend on something....
Like how xz was attacked, everyone pointed at that and no one said they didn't vet their dependencies.
That's the whole point, you attack a dependency that everyone relies on because it's been good and stable. That's how these pyramids build up over time.
So spoiler, it's not unlikely one of the dependencies in your minimal set gets exploited...
Yes, absolutely. It's the bare minimum for people offering commercial products.
Regarding the language itself, I may or may not. Generally, I pick languages that I trust. E.g. I don't trust Google, but I don't think the Go team would intentionally place malware in the core tools. Libraries, however, often are written by random strangers on the internet with a different level of trust.
Because the vast majority of development is done by people with a very narrow focus of skills on an extreme deadline, and you actually comfortable with compression, networking, encryption, IO, and all the other taken for granted libraries that wind up daisy chained together?
Because if you are, great, but at the same time, that's not the job description for like 90% of coding jobs. I don't expect my frontend guy to need to know encryption so he can review the form library he's using.
Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself?
That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.