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

▲

fluoridation 6 days ago | parent | next [-]

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.

▲

wat10000 5 days ago | parent [-]

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.

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

▲

chuckadams 5 days ago | parent | prev [-]

So, what's the acceptable LOC count threshold for using a library?

Maybe scolding and mocking people isn't a very effective security posture after all.

▲

wat10000 5 days ago | parent | next [-]

Time for everybody's favorite engineering answer: it depends! You have to weigh the cost/benefit tradeoff. But you have to do it in full awareness of the costs, including potential costs from packages being taken down, broken, or subverted. In any case, for an external dependency, 100 lines is way too low of a benefit.

I'm not trying to be effective, I'm just lamenting. Maybe being sarcastic isn't a very effective way to get people to be effective?

▲

chuckadams 5 days ago | parent [-]

Naw, sarcasm totally works... ;)

I'd say it all depends -- there's that word again -- on what those 100 LOC are expressing. I suppose one could still copy/paste such a small amount of code, but I'd rather just check in some subset of vendored dependencies. Or maybe just pin the dependency to a commit hash (since we can't depend on version tags being immutable). Something actionable beyond peer pressure at any rate.

	▲	wat10000 5 days ago \| parent [-]
		There are definitely 100-line chunks of code I wouldn't want to rewrite from scratch. They also tend not to be the sort of thing that needs a lot of updates, so a copy/paste job ought to do the job. The big advantage with a dependency manager is that you don't have to find all of the dependency's dependencies, figure out the right build settings, etc. That's super helpful when it's huge, but it's not really doing anything for you when it's small.

▲

tremon 5 days ago | parent | prev [-]

Scolding and mocking is all we're left with, since two decades worth of rational arguments against these types of hazards have been dismissed as fear-mongering.

▲

chuckadams 5 days ago | parent [-]

I don't think we're going to reach a point where "don't use dependencies at all" is a rational argument for most projects.

▲

tremon 5 days ago | parent [-]

It's a good thing then that was not among the rational arguments I was referring to. Do you have other straw men on offer?

	▲	5 days ago \| parent [-]
		[deleted]