4 ms·

> But if you then pull in hundreds of packages in Rust and have 10x as many lines of code... No one is forcing you to use the libraries. Just write your own so

by Ygg2 3y ago

> But if you then pull in hundreds of packages in Rust and have 10x as many lines of code... No one is forcing you to use the libraries. Just write your own software stack yourself. But big problem is vulnerablilities. Is it better to fix hundred libs by fixing a bug in one shared lib or is it better to fix hundred libs one by one?

whstl 3y ago
False dichotomy. What is actually better is to have code that is properly auditable for end-users, or even to not introduce the risk for those vulnerabilities in the first place. Things like Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people, and were hidden inside bloated code. The same thing is happening now with package supply chain.
- Ygg2 3y ago
  It's not a false dichotomy. You either put your vulnerabilities in a few baskets, or you spread (and multiply) them in many more baskets. Neither is intrinsically better. Why multiply? If everyone rolls their own libs, you can expect different library makers to repeat similar mistakes (stuff like not sanitizing input, forgetting to cap anything that generates output from outside sources, etc.). > Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people Minority of people need SSL and logging?!? Most applications need logging, and most of today's applications need the Internet to function. Could have they been omitted when possible? Perhaps, but you're not making a persuasive argument.
  - whstl 3y ago
    I never said people should roll their own. I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. I didn’t make a suggestion, but micro-packages aren’t silver bullets. Deep transitive dependencies are problematic for their lack of visibility, and often a signal of bloat. > Minority of people need SSL and logging?! Heartbleed and Log4Shell weren’t caused by the core SSL or logging code of those libraries, they were caused by code in niche features (heartbeat extension and SAMBA) that should have been plugins (or at least deactivatable by flags). that would massively decrease their impact. Both Heartbleed and Log4Shell were caused by feature bloat and lack of auditability.
    - Ygg2 3y ago
      > I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. And what is your idea to fix this? > Deep transitive dependencies are problematic and... Gonna stop you right here. Deep transitive dependencies are nothing more than huh, other library find this functionality useful, let's pull it into a library. By not having deep dependencies, you are in no uncertain terms claiming everyone should write their own. Or God forbid copying code into your own project. Imagine for a moment we write a set of perfect auditable libraries. Fuzzed, written to spec, proven correct & fast in theory and practice. Guess what? Everyone and their mother will use it, leading to deep transitive dependencies. The complexity of consumer hardware and software requires that even trivial libraries carry with them many dependencies. The alternative is basically Ludditism. Where do you draw the line at what is or isn't bloat? Everyone only uses 20% of the features but in aggregate, they use 110% (10% from Hyrum's Law) of the features.
      - yukkuri 3y ago
        Yes, even the original link admits their "simple is better" solution is only better in limited use cases. "Our software will be so much better quality if it won't do the things you're paying me to make it do" is a non-starter in the real world.
        whstl 3y ago
        You two are talking with a straw man. Nobody ever said anything of the sort.
      - whstl 3y ago
        Fuzzed, proven correct libraries clearly aren't the problem here. But this is really far away from the bulk of Rust or NPM libraries, and it's very naive to pretend that the situation isn't like that. I already mentioned two examples of things that could have been separate from the main libraries (or at least require flags or separate compilation) and caused global problems: heartbeat extensions from OpenSSL and LDAP/JDNI from Log4J. EDIT: I can mention two other examples that I already talked about in this thread: I often come across simple GraphQL-API-consuming apps or libraries that have dependencies on large frontend libraries, while a simple fetch would suffice. The library is needed for introspection, or for building autocomplete clients, but for pure consumption this is unnecessary. Another example are libraries from authors that are splitting code only to bump their NPM or Cargo metrics, like is-odd, or the ora package that has 15 dependencies and a lot are covered by stdlib.
  - yukkuri 3y ago
    Once upon a time I had to track down a catastrophic performance failure (process that should have taken a few minutes couldn't finish in the THREE DAYS allotted to it as a maximum runtime) that turned out to be because it was using a hand-rolled "simple" JSON parser instead of just pulling in Newtonsoft.

by Ygg2 3y ago

whstl 3y ago

False dichotomy. What is actually better is to have code that is properly auditable for end-users, or even to not introduce the risk for those vulnerabilities in the first place. Things like Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people, and were hidden inside bloated code. The same thing is happening now with package supply chain.

Ygg2 3y ago
It's not a false dichotomy. You either put your vulnerabilities in a few baskets, or you spread (and multiply) them in many more baskets. Neither is intrinsically better. Why multiply? If everyone rolls their own libs, you can expect different library makers to repeat similar mistakes (stuff like not sanitizing input, forgetting to cap anything that generates output from outside sources, etc.). > Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people Minority of people need SSL and logging?!? Most applications need logging, and most of today's applications need the Internet to function. Could have they been omitted when possible? Perhaps, but you're not making a persuasive argument.
- whstl 3y ago
  I never said people should roll their own. I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. I didn’t make a suggestion, but micro-packages aren’t silver bullets. Deep transitive dependencies are problematic for their lack of visibility, and often a signal of bloat. > Minority of people need SSL and logging?! Heartbleed and Log4Shell weren’t caused by the core SSL or logging code of those libraries, they were caused by code in niche features (heartbeat extension and SAMBA) that should have been plugins (or at least deactivatable by flags). that would massively decrease their impact. Both Heartbleed and Log4Shell were caused by feature bloat and lack of auditability.
  - Ygg2 3y ago
    > I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. And what is your idea to fix this? > Deep transitive dependencies are problematic and... Gonna stop you right here. Deep transitive dependencies are nothing more than huh, other library find this functionality useful, let's pull it into a library. By not having deep dependencies, you are in no uncertain terms claiming everyone should write their own. Or God forbid copying code into your own project. Imagine for a moment we write a set of perfect auditable libraries. Fuzzed, written to spec, proven correct & fast in theory and practice. Guess what? Everyone and their mother will use it, leading to deep transitive dependencies. The complexity of consumer hardware and software requires that even trivial libraries carry with them many dependencies. The alternative is basically Ludditism. Where do you draw the line at what is or isn't bloat? Everyone only uses 20% of the features but in aggregate, they use 110% (10% from Hyrum's Law) of the features.
    - yukkuri 3y ago
      Yes, even the original link admits their "simple is better" solution is only better in limited use cases. "Our software will be so much better quality if it won't do the things you're paying me to make it do" is a non-starter in the real world.
      - whstl 3y ago
        You two are talking with a straw man. Nobody ever said anything of the sort.
    - whstl 3y ago
      Fuzzed, proven correct libraries clearly aren't the problem here. But this is really far away from the bulk of Rust or NPM libraries, and it's very naive to pretend that the situation isn't like that. I already mentioned two examples of things that could have been separate from the main libraries (or at least require flags or separate compilation) and caused global problems: heartbeat extensions from OpenSSL and LDAP/JDNI from Log4J. EDIT: I can mention two other examples that I already talked about in this thread: I often come across simple GraphQL-API-consuming apps or libraries that have dependencies on large frontend libraries, while a simple fetch would suffice. The library is needed for introspection, or for building autocomplete clients, but for pure consumption this is unnecessary. Another example are libraries from authors that are splitting code only to bump their NPM or Cargo metrics, like is-odd, or the ora package that has 15 dependencies and a lot are covered by stdlib.
- yukkuri 3y ago
  Once upon a time I had to track down a catastrophic performance failure (process that should have taken a few minutes couldn't finish in the THREE DAYS allotted to it as a maximum runtime) that turned out to be because it was using a hand-rolled "simple" JSON parser instead of just pulling in Newtonsoft.