←back to thread

441 points longcat | 5 comments | | HN request time: 0.001s | source
Show context
f311a ◴[] No.45038992[source]
People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year.

This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simple, and everyone can understand the code. It just clears the terminal output and redraws it every second. It is also thread-safe. Took me 25 minutes to integrate it and review the code.

If you don't need a complex stats counter, a simple progress bar is like 30 lines of code as well.

This is a way to go for me now when considering another dependency. We don't have the resources to audit every package update.

replies(17): >>45039115 #>>45039225 #>>45039464 #>>45039724 #>>45039994 #>>45040021 #>>45040056 #>>45040113 #>>45040151 #>>45040162 #>>45040972 #>>45041479 #>>45041745 #>>45044165 #>>45045435 #>>45045983 #>>45052913 #
christophilus ◴[] No.45039724[source]
I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.
replies(4): >>45040074 #>>45040499 #>>45040548 #>>45041307 #
hvb2 ◴[] No.45040074[source]
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.

replies(2): >>45040171 #>>45042915 #
1. 3036e4 ◴[] No.45040171[source]
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.
replies(1): >>45040208 #
2. hvb2 ◴[] No.45040208[source]
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....

replies(1): >>45041278 #
3. 3036e4 ◴[] No.45041278[source]
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.
replies(1): >>45043234 #
4. hvb2 ◴[] No.45043234{3}[source]
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...

replies(1): >>45044808 #
5. jen20 ◴[] No.45044808{4}[source]
> 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.