Re:Dependency Confusion: How I Hacked Into Apple, Microsoft ...
by bluefirebrand on Wednesday February 10, 2021 @11:55AM
(#26091671)
> Need a bit of code that would take you a day to write?
Even if it is a small library that has only a single maintainer the chances of you replicating it in a day seem slim to me unless it is truly trivial, or the library was also written in a day.
More likely you get a day in and realize that the problem has a whole bunch of gotchas that you didn't anticipate and the library maintainer already found and dealt with.
Again, this is only if the problem isn't truly trivial
Re:Dependency Confusion: How I Hacked Into Apple, Microsoft ...
by Robotbeat on Wednesday February 10, 2021 @06:05PM
(#26096082)
Usually you don’t need the entire functionality of a library. So writing something for your use case may only take a day.
Re:Dependency Confusion: How I Hacked Into Apple, Microsoft ...
by edenhyacinth on Wednesday February 10, 2021 @01:12PM
(#26092748)
The left-pad situation wasn't simply that lots of projects were relying on left-pad directly, it was that they were relying on projects that were relying on projects that were relying on left-pad.
Some dependencies are too large to rewrite yourself - most statistical suites would fall under this definition - and while accepting their direct code might be acceptable, it's not usually feasible to fork their code and rewrite the parts that aren't. Lots of smaller parts you could write yourself quickly add up.
Re:Dependency Confusion: How I Hacked Into Apple, Microsoft ...
by adamc on Wednesday February 10, 2021 @11:44AM
(#26091490)
Except a lot of projects aren't shipping anything to anyone, they are providing a service. There, you have to assess the effect if the service goes down or is compromised. There is a wide range of significances. If Roll20 (D&D tabletop site) goes down, it may affect their revenue, but no one is going to get hurt. Etc.
Maybe I'm a dinosaur, but I was taught a long time ago to use a dependency only if there was no other feasible alternative, and to thoroughly know every dependency you bring in as if it were your own code, and treat it as such. Because at the end of the day, you're shipping that code to the customer and stamping your name or your company's name on it. It's your reputation on the line, not the person behind the StudMaster69 GitHub account.