3 ms·

Disclaimer: I don't know if this article is factually correct or not... I have neither tested nor looked at the codebase... But I did find this neat phrase in

Disclaimer: I don't know if this article is factually correct or not... I have neither tested nor looked at the codebase... But I did find this neat phrase in the article: >"Many projects consumed core-js, usually not directly, but rather, somewhere in the nether of the NPM dependency hellscape. Its code, at least indirectly through dependency poisoning, is used almost everywhere." "Dependency Poisoning" -- Now, there's a term that is going into my 2023 lexicon... To generalize (and define better), "Dependency Poisoning" is what happens when codebase A from one author or authors depends on codebase B from another author or authors, and codebase B has a problem or problems with it -- that "poison" or -- cause problems to codebase A. "Dependency Poisoning" -- may be accidental, or it may be intentional. It could also occur as part of a series of nested dependencies, for example, A depends on B which in turn depends on (and imports) C -- if C is "poisoned", typically so is A... Use in a sentence: "If project A uses and depends on <xyz>SSH, and <xyz>SSH has a security bug, then project A has that same security bug by dependency poisoning..."

swatcoder 4y ago
It’s fantastic and exciting that you’re learning this. The very idea of dynamically and blindly sucking third-party code into your project is insane. Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so! But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies. That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things. Thankfully, we seem like we’re finally starting to find our way out of it.
- peter_d_sherman 4y ago
  >It’s fantastic and exciting that you’re learning this. It’s fantastic and exciting that you’re responding... >The very idea of dynamically and blindly sucking third-party code into your project is insane. Agreed -- but in some cases/situations/circumstances it may be necessary... >Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so! Linux being the prime example of this... >But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies. Most Linux Package Managers -- with respect to the nested sub-dependencies that they import -- are the prime example of this... >That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things. Any technology where the people who must maintain it, can no longer understand it due to spiraling and out of control complexity, is broken by definition... >Thankfully, we seem like we’re finally starting to find our way out of it. You and other enlightened thinkers like yourself might indeed be starting to find your way out of it -- but if I have observed one persistent truth it is that as time evolves, technology becomes more complex (with more nested dependencies) and thus more difficult to understand/control -- albeit (again, over time) provides many more conveniences to end users... But, the main point of my post was about linguistics...

swatcoder 4y ago

It’s fantastic and exciting that you’re learning this. The very idea of dynamically and blindly sucking third-party code into your project is insane. Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so! But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies. That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things. Thankfully, we seem like we’re finally starting to find our way out of it.

peter_d_sherman 4y ago
>It’s fantastic and exciting that you’re learning this. It’s fantastic and exciting that you’re responding... >The very idea of dynamically and blindly sucking third-party code into your project is insane. Agreed -- but in some cases/situations/circumstances it may be necessary... >Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so! Linux being the prime example of this... >But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies. Most Linux Package Managers -- with respect to the nested sub-dependencies that they import -- are the prime example of this... >That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things. Any technology where the people who must maintain it, can no longer understand it due to spiraling and out of control complexity, is broken by definition... >Thankfully, we seem like we’re finally starting to find our way out of it. You and other enlightened thinkers like yourself might indeed be starting to find your way out of it -- but if I have observed one persistent truth it is that as time evolves, technology becomes more complex (with more nested dependencies) and thus more difficult to understand/control -- albeit (again, over time) provides many more conveniences to end users... But, the main point of my post was about linguistics...