Is that realistic though? What you're proposing is letting go of abstractions completely.

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.

Small, trivial, things, each solving a very specific problem, and that can be fully understood, sounds pretty amazing though. Much better than what we have now.

That's what a package is supposed to solve, no?

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....

Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.

So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke?

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...

> So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke?

Yes, absolutely. It's the bare minimum for people offering commercial products.

Yes. I would review any changes to any 3rd party libraries. Why is that unrealistic?

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.

> Why is that unrealistic?

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.

Why would a form library have encryption? That's a red flag for me.

How realistic it is depends on how big your dependencies are (in total LOC, not 'number of packages' - something I think gives rust's ecosystem a bad rap, given the tendency for things to be split into lots of packages so the total amount of code you pull in can be minimised). For many projects the LOC of dependencies utterly dwarfs the amount of code in the project itself, and it's pretty infeasible to review it all.

Good for you, but sadly, most people are not like you. Or don't have the opportunity to be like you.

That what I used git submodules for. I had a /lib folder in my project where the dependencies were pulled/checked out from. This was before I was doing CI/CD and before folks said git submodules were bad.

Personally, I loved it. I only looked and updating them when I was going to release a new version of my program. I could easily do a diff to see what changed. I might not have understood everything, but it wasn't too difficult to see 10-100 line code changes to get a general idea.

I thought it was better than the big black box we currently deal with. Oh, this package uses this package, and this package... what's different? No idea now, really.

That’s called the original Go package manager and it was pretty terrible

I think it was only terrible because the tooling wasn't great. I think it wouldn't be too terribly hard to build a good tool around this approach, though I admittedly have only thought about it for a few minutes.

I may try to put together a proof of concept, actually.

If you're working in Go, you don't need to put together a proof of concept. Very basic project tooling in conjunction with "go mod vendor", which takes care of copying in the dependencies in locally, will do what you're talking about. Go may not default to this operation, but using it this way is fairly easy.

sounds like the best way to miss critical security upgrades

That’s why most mature (as in disciplined) projects have a rss feed or a mailing list. So you know when there’s a security bug and what to do about it.

Why? If you had a package manager tell you "this is out of date and has vulnerability XYZ", you'd do a "gitpkg update" or whatever, and get the new code, review it, and if it passes review, deploy it.