Cull your dependencies • Hacker News Board

Re: Cull your dependencies

#91

Post by nemothekid » Fri, Jun 10, 2022, 5:23 PM UTC

cvccvroomvroom wrote: post #76

EdSchouten wrote: post #13

I don't think there's an issue with depending on libraries that are big. If the library is just a big bag of classes from which you cherry-pick the ones you need, then the extrapolation on the number of bugs as mentioned in the article under "By the numbers" is meaningless. Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? In modern languages like Go or Rust, it wil…

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library?

IMO, the OP post has an unfounded sense of hubris. Everyone else's code is bad except for me, who only writes minimal code with no exploits.

Re: Cull your dependencies

#93

Post by lamontcg » Fri, Jun 10, 2022, 5:55 PM UTC

Beginner developers constantly reinvent the wheel

Intermediate developers use frameworks and code that already exists to avoid reinventing the wheel.

Expert developers use thin frameworks and minimize the external dependencies they need and maintain an internal library of simple foundational methods.

Re: Cull your dependencies

#94

Post by matt_heimer » Fri, Jun 10, 2022, 6:00 PM UTC

ape4 wrote: post #16

Is there a minimal replacement for log4j?

The built-in JUL package seems to be what you'd want if you are trying get rid of dependencies. In practice I find that using slf4j as your logging API is a good practice. You can start with it configured to be a wrapper around JUL and then add a different logging implementation if you need more features like file rotation, etc.

Re: Cull your dependencies

#95

Post by lamontcg » Fri, Jun 10, 2022, 6:09 PM UTC

smarx007 wrote: post #41

It's a good advice but it has a cost. Where is the discussion about cost? The product with less dependencies will live longer and give you better flexibility but it will cost more to build and more to maintain (incl. onboarding new engineers who need to learn their way around your custom stdlib+). It's a balanced choice but the stakeholders are not prepared to invest more. Furthermore, if the project gets cancelled,…

It is an optimization problem, and any strawman argument based on the alternative endpoints will be flawed.

It is also very difficult to measure the mitigation of issues caused by reducing dependencies and exposure to their issues. If you try to measure it, you'll wind up only seeing costs, and will wind up using all kind of dependencies up until you start seeing how hard it is to maintain your own CI and then you eventually get log4j'd.

Re: Cull your dependencies

#96

Post by spfzero » Fri, Jun 10, 2022, 6:13 PM UTC

nemothekid wrote: post #91

cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library? IMO, the OP post has an unfounded sense of hubris. Everyone else's code is bad except for me, who only writes minimal code with no exploits.

He's not comparing quality, as much as quantity. Building a small utility function, general enough for your intended use, brings in less code than adding a library dependency. That's the argument.

TLS is an example of when you probably would not make that trade-off, but there are lots of other examples where it would make sense.

Re: Cull your dependencies

#97

Post by SheinhardtWigCo » Fri, Jun 10, 2022, 6:15 PM UTC

cvccvroomvroom wrote: post #76

EdSchouten wrote: post #13

I don't think there's an issue with depending on libraries that are big. If the library is just a big bag of classes from which you cherry-pick the ones you need, then the extrapolation on the number of bugs as mentioned in the article under "By the numbers" is meaningless. Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? In modern languages like Go or Rust, it wil…

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

I'll say the quiet part out loud: nobody got fired for using a dependency with any of these bugs, and nobody got promoted for not doing so.

Obviously, pulling in something like left-pad is worthy of derision. But generally you should pull in whatever dependencies let you go faster, and minimize the amount of time spent planning for black swan events.

Re: Cull your dependencies

#98

Post by pitched » Fri, Jun 10, 2022, 6:20 PM UTC

bertr4nd wrote: post #85

cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

But what’s the back pressure to this advice? If I need to multiply matrices should I write my own to avoid including MKL BLAS? What’s the heuristic that determines when a dependency is worthwhile?

I have written a matrix multiplication lib once because I had some a priori about the data and could remove half the operations.

Everything has a cost (usually in time) and everything comes with trade offs (usually a different set of bugs). Not-invented-here comes with a gigantic upfront time cost and a larger set of bugs. The best heuristic depends on what you’re optimizing for. There’s never an easy answer.

Re: Cull your dependencies

#99

Post by X6S1x6Okd1st » Fri, Jun 10, 2022, 6:24 PM UTC

One of the pains I've experienced over ~1 decade as a professional SWE is that a lot of dependencies aren't really maintained. Many of the times I've diagnosed an issue in one of our dependencies only to find that the maintainer isn't really present or interested in upstreaming.

Many companies are uninterested in forking and maintaining their own version either

Re: Cull your dependencies

#100

Post by mcdonje » Fri, Jun 10, 2022, 6:25 PM UTC

nemothekid wrote: post #91

cvccvroomvroom wrote: post #76

Earlier quoted context omitted.

HeartBleed, Spring4Shell, LogJam, Struts, Jetty and many more beg to differ. More LoC is always a greater attack surface, regardless of development trustworthiness. Minimize code ruthlessly.

The corollary to "Minimize code ruthlessly" is "Roll your own X". Sure Heartbleed was bad, but are you going to write your own TLS library? IMO, the OP post has an unfounded sense of hubris. Everyone else's code is bad except for me, who only writes minimal code with no exploits.

Libraries are generally larger because they are usually written for more use-cases. If your program is only referencing a small portion of a library, then rolling your own doesn't mean rewriting the library. Your code will be more minimal because it's only written for your program.

Assuming you're fallible and write code with exploits like everyone else, your program will probably have different exploits from mine. An attacker won't be able to target a widely used library and enjoy being able to pick from several targets. Instead, they'll have to tailor an attack for your code base. Each exploit found yields less of a reward, which will frustrate less motivated attackers.