←back to thread

441 points longcat | 1 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 #
wat10000 ◴[] No.45039225[source]
Part of the value proposition for bringing in outside libraries was: when they improve it, you get that automatically.

Now the threat is: when they “improve” it, you get that automatically.

left-pad should have been a major wake up call. Instead, the lesson people took away from it seems to have mostly been, “haha, look at those idiots pulling in an entire dependency for ten lines of code. I, on the other hand, am intelligent and thoughtful because I pull in dependencies for a hundred lines of code.”

replies(2): >>45039649 #>>45040119 #
fluoridation ◴[] No.45039649[source]
The problem is less the size of a single dependency but the transitivity of adding dependencies. It used to be, library developers sought to not depend on other libraries if they could avoid it, because it meant their users had to make their build systems more complicated. It was unusual for a complete project to have a dependency graph more than two levels deep. Package managers let you easily build these gigantic dependency graphs with ease. Great for productivity, not so much for security.
replies(1): >>45040061 #
wat10000 ◴[] No.45040061[source]
The size itself isn’t a problem, it’s just a rough indicator of the benefit you get. If it’s only replacing a hundred lines of code, is it really worth bringing in a dependency, and as you point out potentially many transitive dependencies, instead of writing your own? People understood this with left-pad but largely seemed unwilling to extrapolate it to somewhat larger libraries.
replies(1): >>45042074 #
1. 3036e4 ◴[] No.45042074[source]
You are probably bringing in 10-1000 lines of code for every 1 line you did not have to write (I am sure some good estimate could be calculated?), since all the libraries support cases you do not need. This also tends to result in having to use APIs that are far more complex than they have to be. In addition to security risks.