5 ms·

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 nee

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 will most likely not even compile the code you don't care about, assuming it lives in separate packages/modules. What's a lot more problematic is if you use libraries that don't allow easy cherry-picking. For example, Log4j has a very simple API à la log.print(), but that thing almost acts like a portal into another universe. Strings can contain a whole bunch of modifiers or tags that cause the library to do many special things that are enabled by default. Those libraries are just poor in taste.

deleted 4y ago
[deleted]
vlovich123 4y ago
Don’t be so sure. Large libraries often aren’t well-separated and so you end up not being able to strip as much as you intend (unless there’s an explicit design goal that’s somehow enforced to keep things in isolated components). If you can’t strip, that means there’s a dependency somewhere which means you may end up exercising code you didn’t intend. Log4j is an extreme example and generalizing from it to all libraries is bad engineering but paying attention to dependency graphs is a good idea even if people will continue to ignore the problem.
- cvccvroomvroom 4y ago
  OpenSSL is everything and the kitchen sink feature creep. Their development and architecture methodology are nil.
cvccvroomvroom 4y ago
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.
- bertr4nd 4y ago
  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?
  - pitched 4y ago
    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.
  - patrick451 4y ago
    As usual, it depends. A naive matrix multiplication function is pretty simple. If that's all you need and can do with sub-optimal performance, I'd write my own.
- nemothekid 4y ago
  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.
  - cvccvroomvroom 4y ago
    Yes, of course. Unless you absolutely have known working pristine code free of side-channels for SHA3, ChaCha20-Poly1305, etc. don't even think about it. The same goes for parsing and other complicated operations containing pitfalls. Honestly, I hope most crypto, parsing, numerics libs, and OS kernels and drivetd were rewritten in Rust and given C, C++, etc. interfaces.
  - spfzero 4y ago
    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.
kixiQu 4y ago
> Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? If things are segmented in ways such that you can automatically tell that you're not impacted by a bug, cool. A lot of log4j emergency deployment pain in BigCos had to do with the limitations of tools that could discern whether you weren't impacted, because security vulnerabilities of that magnitude aren't an area where "probably not" is good enough. I wouldn't really be comfortable with "it's fine that my <bank/surgeon/cloud provider> uses a framework with massive unpatched vulnerabilities, they're very careful to hand-pick classes to import that are safe". (modulo the security of real world banks/surgeons being, uh, less than ideal, and all of my PII probably being accessible from some wordpress endpoint somewhere)

deleted 4y ago

[deleted]

vlovich123 4y ago

Don’t be so sure. Large libraries often aren’t well-separated and so you end up not being able to strip as much as you intend (unless there’s an explicit design goal that’s somehow enforced to keep things in isolated components). If you can’t strip, that means there’s a dependency somewhere which means you may end up exercising code you didn’t intend. Log4j is an extreme example and generalizing from it to all libraries is bad engineering but paying attention to dependency graphs is a good idea even if people will continue to ignore the problem.

cvccvroomvroom 4y ago
OpenSSL is everything and the kitchen sink feature creep. Their development and architecture methodology are nil.

cvccvroomvroom 4y ago

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.

bertr4nd 4y ago
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?
- pitched 4y ago
  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.
- patrick451 4y ago
  As usual, it depends. A naive matrix multiplication function is pretty simple. If that's all you need and can do with sub-optimal performance, I'd write my own.
nemothekid 4y ago
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.
- cvccvroomvroom 4y ago
  Yes, of course. Unless you absolutely have known working pristine code free of side-channels for SHA3, ChaCha20-Poly1305, etc. don't even think about it. The same goes for parsing and other complicated operations containing pitfalls. Honestly, I hope most crypto, parsing, numerics libs, and OS kernels and drivetd were rewritten in Rust and given C, C++, etc. interfaces.
- spfzero 4y ago
  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.

kixiQu 4y ago

> Why care about bugs in code you don't use if it doesn't even end up getting linked into your program? If things are segmented in ways such that you can automatically tell that you're not impacted by a bug, cool. A lot of log4j emergency deployment pain in BigCos had to do with the limitations of tools that could discern whether you weren't impacted, because security vulnerabilities of that magnitude aren't an area where "probably not" is good enough. I wouldn't really be comfortable with "it's fine that my <bank/surgeon/cloud provider> uses a framework with massive unpatched vulnerabilities, they're very careful to hand-pick classes to import that are safe". (modulo the security of real world banks/surgeons being, uh, less than ideal, and all of my PII probably being accessible from some wordpress endpoint somewhere)