Slashdot Mirror


How One Dev Broke Node and Thousands of Projects In 11 Lines of JavaScript (theregister.co.uk)

An anonymous reader quotes an article written by Chris Williams for The Register: Programmers were left staring at broken builds and failed installations on Tuesday after someone toppled the Jenga tower of JavaScript. A couple of hours ago, Azer Koculu unpublished more than 250 of his modules from NPM, which is a popular package manager used by JavaScript projects to install dependencies. Koculu yanked his source code because, we're told, one of the modules was called Kik and that apparently attracted the attention of lawyers representing the instant-messaging app of the same name. According to Koculu, Kik's briefs told him to take down the module, he refused, so the lawyers went to NPM's admins claiming brand infringement. When NPM took Kik away from the developer, he was furious and unpublished all of his NPM-managed modules. 'This situation made me realize that NPM is someone's private land where corporate is more powerful than the people, and I do open source because Power To The People,' Koculu blogged. Unfortunately, one of those dependencies was left-pad. It pads out the lefthand-side of strings with zeroes or spaces. And thousands of projects including Node and Babel relied on it. With left-pad removed from NPM, these applications and widely used bits of open-source infrastructure were unable to obtain the dependency, and thus fell over.

29 of 480 comments (clear)

  1. Re:The guy was ripping off leftpad by phishybongwaters · · Score: 4, Insightful

    See this is the exact scenario I've talked about before, typically when learning a new coding language. Dependancies and libraries are BAD. 1: because they remove the need to understand what's actually going on (premade functions for example) 2: because some asshat could yank them away and leave your project broken, then YOU have to figure out how to replace the dependencies. I get not reinventing the wheel. But you really need to pay attention to what your code is dependent on and remove that dependency if possible

  2. So, in summary by Anonymous Coward · · Score: 4, Insightful

    So, what have we learned?

    External dependencies are unsustainable;

    JavaScript is unmaintainable;

    Dozens of mainstream projects relying on a trivial bit of string padding code from an external JavaScript dependency is unconscionable.

    1. Re:So, in summary by Anonymous Coward · · Score: 2, Insightful

      Dozens of mainstream projects relying on a trivial bit of string padding code from an external JavaScript dependency is unconscionable

      This is the state a *lot* of open source projects are in. Dependency trees that make windows dll hell look sane. We have cranked out thousands of packages like this. Tons of people writing things to get 'resume cred' then immediately forgetting about it after they get a job. The code lives on as a zombie with no one really digging in and taking a look at it.

      Then this little gem "and I do open source because Power To The People" No dude you are throwing a fit and punishing everyone for it. You just showed yourself to be a 'my code is the best and i am taking my ball and going home' sort of guy. You are pissed off that the npm guys did not side with you over a rather minor issue. You also just gave the kik guys some good will and make them look like they have the higher ground. Good luck getting people to accept your pull requests. As they will forever be thinking 'what if he does it again?'.

  3. Re:What a strange name for an IM app... by itamihn · · Score: 4, Insightful

    Everything is one letter away of meaning something in some language.

  4. Lesson for next time ... by BarbaraHudson · · Score: 1, Insightful

    Roll your own libraries. No outside dependencies, and you'll probably leave out a lot of the cruft that is there "because."

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    1. Re:Lesson for next time ... by NotInHere · · Score: 4, Insightful

      So you say everybody should write their own buggy and incomplete reinvention of the wheel?

      Yes, probably most of his libraries aren't longer than 2000 lines of code, and therefore are pretty replaceable, but I don't think that writing your own libraries will decrease the total number of bugs, it will rather increase them.

  5. Re:oh vanity... by The+Evil+Atheist · · Score: 2, Insightful

    Yeah, because should only apply their ethics when you say it's okay. How vain of people to care about their personal ethics.

    --
    Those who do not learn from commit history are doomed to regress it.
  6. Re:The guy was ripping off leftpad by Lisandro · · Score: 5, Insightful

    Dependencies are unavoidable, specially on big projects - you are not expected to reinvent the wheel every time you code.

    Now, having a dedicated library dependency for padding strings is a bit of a stretch though...

  7. Anybody surprised? by gstoddart · · Score: 5, Insightful

    I've always thought this interconnected pile of stuff, linking across a bunch of domains was lazy, dangerous, and likely to be very brittle.

    Sorry, but the interwebs have shown me I can't afford to trust arbitrary code from all over the place, which can change at a moments notice, and which I know nothing about.

    If you've created an infrastructure where tons of stuff breaks because some asshole corporation forces some guy to say "fuck you, you can't have my code", you have a terrible mess. What happens if someone adds some malicious code?

    What I find really odd is they've over-ruled him and said "no, you can't un-publish your own stuff, we own it". So, what, they've decided his stuff was too important to still be his own? So he got fucked because of corporate assholes only to have his copyright infringed?

    Jenga tower indeed, it sounds like the state of the art is a bunch of brittle dependencies controlled by a few places, and subject to causing a shit top of things to happen when someone makes a change.

    This reminds me of a company I worked at which had a universal build system ... everything build from scratch every day and wouldn't build if any of its dependencies didn't build. So when some guy broke a components 3 components upstream, nobody could get anything compiled because the system was too stupid to go with the last known good ... and hundreds of developers sat around all day going "but, what do you mean we can't do anything because some guy checked in shit code".

    And that's how JavaScript app development works in 2016.

    Wow, just wow.

    Steaming Heaps of Innovative Technology.

    --
    Lost at C:>. Found at C.
    1. Re:Anybody surprised? by jareth-0205 · · Score: 3, Insightful

      What I find really odd is they've over-ruled him and said "no, you can't un-publish your own stuff, we own it". So, what, they've decided his stuff was too important to still be his own? So he got fucked because of corporate assholes only to have his copyright infringed?

      *sigh* We really shouldn't still be having this conversation about how open source licensing works, but OK: They don't claim to own it, but they can redistribute it under the same licence that it was being distributed under. His copyright isn't infringed, it just remains distributed under the non-reversible licence that he chose to distribute it under in the first place.

  8. Re:The guy was ripping off leftpad by nedlohs · · Score: 5, Insightful

    Bullshit.

    Dependencies and libraries are fine. If you want to use SSL encryption in your software you should try and re-implement it all, because while SSL libraries have been having security issues in the last few years there's almost zero chance you make something that doesn't have bigger ones. Multiply that by all the domain specific pieces of code you need.

    Not having to understand what's actually going on is a feature not a problem.

    What is retarded is using a dependency that exists out in the internet somewhere only, so that your code breaks if some random internet service disappears. As long as you have your own copy of the dependency it's fine. Some asshat can't yank them away since you have your own copy that doesn't magically stop working. Obviously you want the source code, or at the very least the source code escrowed somewhere that you obtain if the provider vanishes in the future.

  9. OPC by Anonymous Coward · · Score: 1, Insightful

    This is what can happen when you use Other People's Code.

    The more a project says "requires" something other than the language it's written in, you're making the risks worse.

    The better the programmer, the less OPC they will use.

    The best programmers are known by the announcement in their projects that their code was black box and has no external project dependencies. If you must use OPC, you should be looking hard for such a statement.

    Of course, today, most "programmers" aren't deserving of the name in the first place. Glorified scriptkiddies at best.

    1. Re:OPC by Delwin · · Score: 5, Insightful

      ... I hope you're kidding. Don't reinvent the wheel - if someone else has already written the code then there's no reason to re-write it. That's a huge waste of man hours. Instead you should package all dependencies in such a way that they can be retrieved without requiring the other guy to still be offering it. Yes, that means a snapshot of the version you rely of should be in your repository because you also can't guarantee that a given version will be available as long as your own project is.

    2. Re:OPC by Luthair · · Score: 5, Insightful

      The AC is too busy to respond, he's currently fixing the 9999999 security flaws in his hand-rolled SSL library.

    3. Re:OPC by mrchaotica · · Score: 4, Insightful

      Using other people's libraries is fine; you just need to keep your own copy of them instead of dynamically-linking (or hotlinking, in the case of Javascript web shit).

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    4. Re:OPC by pla · · Score: 4, Insightful

      I hope you're kidding. Don't reinvent the wheel - if someone else has already written the code then there's no reason to re-write it.

      I hope you're kidding, and the present situation makes an excellent example of why.

      Tracking down Open Source dependencies has become a complete nightmare, in many cases, because far, far too many devs unfortunately take your advice to heart. No, we shouldn't roll our own bigmath libraries, or nosql implementations. But what lazy-assed devs would import an external dependency for something as trivial as padding a string? Oh, right - Apparently thousands of them. Gee, I wonder why the business world doesn't take us seriously, despite offering them our work for the low, low price of "free"?

    5. Re:OPC by phantomfive · · Score: 3, Insightful

      You got me interested, and with efficiency you can never be sure until you time it, so I wrote a program to time it. Looping from zero to a billion, with an assignment inbetween. Then I recompiled and ran it again, this time going backwards to zero. Here are some times (in milliseconds):

      Going up: 32453 / 32536 / 32232 / 32604
      Going down: 32587 / 32416 / 32216 / 32466

      There seems to be no difference at all in either direction. Code is here.

      --
      "First they came for the slanderers and i said nothing."
  10. Re:And nothing of value was lost by __aaclcg7560 · · Score: 3, Insightful

    Your left pad solution is 40% shorter and probably more efficient than the crap that was yanked from NPM.

    The original code from NPM is more readable. Given the choice between compact code and readable code, I prefer readable code. Especially when it comes to my own code and I have to figure out what I wrote months or years later.

  11. Re:The guy was ripping off leftpad by rockmuelle · · Score: 4, Insightful

    Dependencies are unavoidable, true, but it's a good practice to vet libraries before you include them and make sure they're worth the risk.

    The risk with Open Source libraries is usually long term maintenance - will the project be maintained for the lifetime of my project? If the project is not maintained, is it something you're willing to take on and will the license and community let you fork it? If not, there's risk.

    You also have the risk we see here - ideology trumping pragmatism (that's a nice way of saying the developer had a fit and took his toys away for reasons even he doesn't fully understand). In those cases, you also have the chance to fork, assuming the license/community allows it.

    For trivial operations, such as left padding, it's almost never worth the risk to use a library unless it's part of the language's standard library. Sure, don't write your own FFT or ORM, but if you can code a function in a few minutes for a well defined problem, there's no reason to add an external dependency.

    -Chris

  12. Re:oh vanity... by retchdog · · Score: 2, Insightful

    The downstream impact of my dump is comparable to the downstream impact of 99% of github bullshit. That's the analogy.

    Some things are not worth agonizing over, or "discretion is the better part of valor".

    --
    "They were pure niggers." – Noam Chomsky
  13. Re:Unavoidable if you're LAZY by Lisandro · · Score: 4, Insightful

    Nonsense. Laughable, even. Quality programmers can build anything. If they're wise, they will.

    I guess you never worked with code then, eh? It is not about whether they can or cannot - is about the resources involved. Writing and testing a production-level software library is not a trivial task. It takes time.

    Again, this does not apply to string padding, which is usually resolved on a couple lines of code on the language of your choice...

  14. JAVASCRIPT NEEDS TO GO! by Anonymous Coward · · Score: 3, Insightful

    It's fucking unbelievable how much trouble JavaScript has caused for so many people.

    Let's ignore how fundamentally broken it is, as a programming language, in almost every respect. That includes its fucking awful type system, its total lack of real OO (sorry, prototypes are complete shit), its ultra shitty standard library (which is why NPM and this problem exist in the first place), and similar problems.

    JavaScript has allowed too many unskilled cranks to shit out way too much broken code. It was one thing when they did it client-side, where it was isolated. Now it's being done server-side, and it's a motherfucking disaster!

    Worse, JavaScript has enabled the web advertising industry. JavaScript makes it trivial for them to track your every move online. If you don't want to fall victim to it, then you have to waste your time disabling it everywhere by default, and selectively enabling it where you need it.

    JavaScript needs to go.

    If you really need to use a scripting language server-side, use Lua, or Python, or even goddamn Tcl. All three of them are better than JavaScript in every way.

    1. Re:JAVASCRIPT NEEDS TO GO! by Penguinisto · · Score: 4, Insightful

      ...and Docker is the new Solaris Zones. Err, okay?

      The point isn't that node.js sucks (personal opinion - it kinda does when mishandled, just like PHP), it's that like any tool, you have to use it correctly and try not to make it do shit that it wasn't designed to do.

      We see this shit in Puppet-land, where so-called DevOps people rely on external github (not puppetforge, but random github) modules to run their servers. They never pull a local copy, but instead use something like Librarian to pull it in dynamically... never realizing that if the guy maintaining $randomModule says 'fuck it' and pulls his project (or even just breaks his module), suddenly you're stuck with a broken model and a potential outage.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
  15. Re:What is Kik? by AmiMoJo · · Score: 4, Insightful

    True, but lawyers don't understand those words, they just know it's about computers so anything computer related called "kik" must die. They are like marauding barbarians, waving their clubs in the air and smashing anything that looks a bit like the magic rock they worship.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  16. Build a mirror for your dependencies! by damaki · · Score: 5, Insightful

    Thou shalt always mirror your dependencies. Never assume that everything will always be available. That's continuous integration 101.
    Second paradigm: mirror even your dependencies source code, if you can.

    --
    Stupidity is the root of all evil.
  17. Re:What is Kik? by Anonymous Coward · · Score: 2, Insightful

    Yeah but that's not how they think.

    They're not real lawyers. They're a "brand management" company that was hired over a game of golf. Their job is to prove that they are useful to their clients.

    So they fire up a search engine and find every instance of the word 'kik', then send legal flavored nastygrams to everyone they can find. In some cases they harass poor developers working on js projects.

    Then they put it all in a report and give it to their employer to 'prove' how much they protected their 'brand'

    They don't give a wet fart about the consequences as there are effecively zero legal repercussions for this behavoir.

  18. It's the "Hipster False Switcheroo" fallacy! by Anonymous Coward · · Score: 0, Insightful

    Your comment is a superb specimen of the Hipster False Switcheroo fallacy!

    It has all of the main characteristics.

    Firstly, it involves a topic that hipsters hold dear: JavaScript.

    Secondly, you've taken what was a sane, reasonable argument, and switched the words around to turn it into a failed, off-topic, irrelevant "argument" that's factually wrong.

    Thirdly, you're oblivious to how your "argument" is failed, off-topic, and irrelevant.

    Fourthly, you got wrongfully upmodded by some other hipster fool here.

    What a fine specimen, indeed! It's almost like you went through a checklist to finely craft it.

    Wait, that's a newly-discovered fifth characteristic!

    Fifthly, you've put more effort into creating your failed, off-topic, and irrelevant "argument" than you've put into the artisanal bread you attempt to bake.

  19. YOUR MOTHER NEEDS TO GO! by Anonymous Coward · · Score: 0, Insightful

    It's fucking unbelievable how much trouble your mother has caused for so many people.

    Let's ignore how fundamentally broken it is, as a mother, in almost every respect. That includes its fucking awful tit system, its total lack of real OO (sorry, implants are complete shit), its ultra shitty standard library (which is why she can't read in the first place), and similar problems.

    your mother has allowed too many unskilled cranks to shit out way too much broken fuck. It was one thing when they did it client-side, where it was isolated. Now it's being done mother-side, and it's a mother fucking disaster!

    Worse, your mother has enabled the web advertising industry. your mother makes it trivial for them to track your every move online. If you don't want to fall victim to it, then you have to waste your time disabling it everywhere by default, and selectively enabling it where you need it.

    your mother needs to go.

    If you really need to use a mother, use Lua, or Python, or even goddamn Tcl. All three of them are better than your mother in every way.

  20. Re:oh vanity... by firewrought · · Score: 5, Insightful

    Missing from your list is that NPM didn't just pull the npm package, they reassigned it to a different user. Think about the security implications of that... it implies anyone can send a few intimidating emails, gain control of a major project, and then substitute with their own code/malware.

    Assuming that's how it played out, it might be a good thing the developer threw a hissy fit: the resulting public fallout may or may not prompt NPM (and NuGet, Cargo, Docker, and so forth) to reconsider the trust problem they have created.

    --
    -1, Too Many Layers Of Abstraction