7 ms·

"sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand" Yes you must re

by wolco 6y ago

"sure: it is totally their fault for deploying something without carefully reading your code to figure out that it was a bit shitty beforehand" Yes you must read and understand everything or have trust in the publisher. Relying on the package name is going to get you in trouble. Sounds like a great exploit opportunity.

sabas123 6y ago
What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant). As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.
- TeMPOraL 6y ago
  > As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all. In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
  - bigiain 6y ago
    Hands up everybody who remembers "Matt's Script Archive"? (Hmmm, just the greybeards. I could have guessed that I suppose...)
- watwut 6y ago
  One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed. So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution. Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
- catalogia 6y ago
  There are many things short of reading the code in full you can do to lower the chances of this happening. A lot of half-assed libraries have obviously incomplete APIs that you can notice if you think about the interface provided and the nature of what the library claims to be doing. You can also look at repo activity; was it all coded in one week 8 years ago and never touched again? Does it have lots of outstanding issues? Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.
  - RussianCow 6y ago
    This. In my experience, GitHub issues and PRs tell you most everything you need to know about an open source library: if issues are responded to (and how quickly), the attitude of the maintainer with regards to new features, etc. Most of this can be gleamed within 20 minutes of browsing, and when you combine that with a quick 5-minute look at dependencies and tests, you can make a pretty good, educated decision about whether to use the library, and those 25-30 minutes save you hours or days of potential headaches down the road.
bigiain 6y ago
I would like to draw to your attention the magnitude of that task, with a recent link from another HN comment discussion: http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native and https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste... Turns out left-pad.js is on line 8571 of that 14+k line yarn.lock file. How many React Native developers do you suppose have reviewed every line of code in every library referenced in that file? (Or even how many engineering teams at any React-using Unicorn size startups or FAANG have exhaustively reviewed all those lines of code?) Is FaceBook a "trusted publisher" of React? Is npm a "trusted publisher" of Node libraries? Was Azer Koçulu a "trusted publisher" of left-pad.js? (And it's turtles all the way down. Is Microsoft a "trusted publisher" of Windows? Is Dell a "trusted publisher" of bios? Is Intel a "trusted publisher" of cpu micro-code? Is Western Digital a "trusted publisher" of hard drive firmware? Is every unnamed silicon manufacturer and pcb and subcomponent assembly house a "trusted publisher" of the embedded code in their network card/usb hub/battery management chip/whatever?) I _do_ agree with you, but these days it's very difficult, at least in much/most of the software world, to determine the height of the people/libraries claiming to be "giants" offering their shoulders to stand on. (And like with React, it's more and more difficult to determine which actual giants are standing on bedrock, and which have a foothold with quicksand uderneath it...)
- wolco 6y ago
  In react's case you put your trust in facebook and because of the size most issues get discovered and someone has an article on how to fix before breakfast. When you include left-pad in your own project you should audit it. In the end you are the only line of defense. With react it's larger so you can trust others.
  - gpeal 6y ago
    I think that's exactly the problem because of things like this: https://twitter.com/ZacSweers/status/1259176799235387393?s=19 https://twitter.com/ZacSweers/status/1259176799235387393?s=1... I am the sole maintainer of airbnb/lottie-android despite the fact that I left the company almost 2 years ago and it is used by tens of thousands of companies including Google, Samsung, Microsoft, Uber, Netflix, and countless others.
namelosw 6y ago
Most of time it's just trust. It's not possible to read through node modules, or reason about C compilers, or even inspect the source code of the operating systems.
stevenwliao 6y ago
Who has read through all the code of their direct dependencies, let alone transitive ones?
- deleted 6y ago
  [deleted]

by wolco 6y ago

sabas123 6y ago

What if I have no reasonable way of fully understanding the code nor being able to judge the author on their trustworthiness (even disregarding that this isn't constant). As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.

TeMPOraL 6y ago
> As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all. In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.
- bigiain 6y ago
  Hands up everybody who remembers "Matt's Script Archive"? (Hmmm, just the greybeards. I could have guessed that I suppose...)
watwut 6y ago
One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed. So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution. Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.
catalogia 6y ago
There are many things short of reading the code in full you can do to lower the chances of this happening. A lot of half-assed libraries have obviously incomplete APIs that you can notice if you think about the interface provided and the nature of what the library claims to be doing. You can also look at repo activity; was it all coded in one week 8 years ago and never touched again? Does it have lots of outstanding issues? Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.
- RussianCow 6y ago
  This. In my experience, GitHub issues and PRs tell you most everything you need to know about an open source library: if issues are responded to (and how quickly), the attitude of the maintainer with regards to new features, etc. Most of this can be gleamed within 20 minutes of browsing, and when you combine that with a quick 5-minute look at dependencies and tests, you can make a pretty good, educated decision about whether to use the library, and those 25-30 minutes save you hours or days of potential headaches down the road.

bigiain 6y ago

I would like to draw to your attention the magnitude of that task, with a recent link from another HN comment discussion: http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native and https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste... Turns out left-pad.js is on line 8571 of that 14+k line yarn.lock file. How many React Native developers do you suppose have reviewed every line of code in every library referenced in that file? (Or even how many engineering teams at any React-using Unicorn size startups or FAANG have exhaustively reviewed all those lines of code?) Is FaceBook a "trusted publisher" of React? Is npm a "trusted publisher" of Node libraries? Was Azer Koçulu a "trusted publisher" of left-pad.js? (And it's turtles all the way down. Is Microsoft a "trusted publisher" of Windows? Is Dell a "trusted publisher" of bios? Is Intel a "trusted publisher" of cpu micro-code? Is Western Digital a "trusted publisher" of hard drive firmware? Is every unnamed silicon manufacturer and pcb and subcomponent assembly house a "trusted publisher" of the embedded code in their network card/usb hub/battery management chip/whatever?) I _do_ agree with you, but these days it's very difficult, at least in much/most of the software world, to determine the height of the people/libraries claiming to be "giants" offering their shoulders to stand on. (And like with React, it's more and more difficult to determine which actual giants are standing on bedrock, and which have a foothold with quicksand uderneath it...)

wolco 6y ago
In react's case you put your trust in facebook and because of the size most issues get discovered and someone has an article on how to fix before breakfast. When you include left-pad in your own project you should audit it. In the end you are the only line of defense. With react it's larger so you can trust others.
- gpeal 6y ago
  I think that's exactly the problem because of things like this: https://twitter.com/ZacSweers/status/1259176799235387393?s=19 https://twitter.com/ZacSweers/status/1259176799235387393?s=1... I am the sole maintainer of airbnb/lottie-android despite the fact that I left the company almost 2 years ago and it is used by tens of thousands of companies including Google, Samsung, Microsoft, Uber, Netflix, and countless others.

namelosw 6y ago

Most of time it's just trust. It's not possible to read through node modules, or reason about C compilers, or even inspect the source code of the operating systems.

stevenwliao 6y ago

Who has read through all the code of their direct dependencies, let alone transitive ones?

deleted 6y ago
[deleted]