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.

▲

3036e4 5 days ago | parent | next [-]

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.

▲

hvb2 5 days ago | parent [-]

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

▲

3036e4 5 days ago | parent [-]

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.

▲

hvb2 5 days ago | parent [-]

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

	▲	jen20 5 days ago \| parent [-]
		> 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.

▲

christophilus 5 days ago | parent | prev [-]

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.

▲

Eji1700 5 days ago | parent | next [-]

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

	▲	skydhash 5 days ago \| parent [-]
		Why would a form library have encryption? That's a red flag for me.

▲

ashirviskas 5 days ago | parent | prev | next [-]

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

▲

rcxdude 5 days ago | parent | prev [-]

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.