Slashdot Mirror


Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package (bleepingcomputer.com)

Catalin Cimpanu, reporting for BleepingComputer: The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular -- albeit deprecated -- JavaScript package. The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies. The npm team -- which analyzed this package earlier today after reports from the npm community -- says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library.

88 comments

  1. Re: backdoor ? by Anonymous Coward · · Score: 0

    Well apparantly you have a complex system for receiving...

  2. Re:Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    What the heck is a Zontar?

  3. Frameworks by GWXerog · · Score: 3

    Just more fuel on the dumpster fire. If you *need* a third party to maintain all of your useless frameworks then it's time to stop

    1. Re:Frameworks by Anonymous Coward · · Score: 0

      Hey, no dissing npm, lest the idiots at bleepingcomputing have nothing to blather about.

    2. Re:Frameworks by Anonymous Coward · · Score: 0

      So much this and it reflects in the efficiencies of the teams where I work. Those that have massive dependencies take forever to build anything.

    3. Re:Frameworks by Anonymous Coward · · Score: 0

      Did you post this from a computer that you built yourself with an operating system you wrote yourself?

    4. Re:Frameworks by The+MAZZTer · · Score: 1, Insightful

      So I guess we should just give up on Linux with yum, rpm, and apt?

      Also nuget for .NET stuff but Linux makes a better example.

    5. Re:Frameworks by 605dave · · Score: 3, Funny

      That's different! We do that through the command line so we know it's secure.

      --
      Be kind, for everyone you meet is fighting a difficult battle. - Plato
    6. Re:Frameworks by rainmouse · · Score: 1

      Yeah why bother with distributed shared effort when you can reinvent the wheel in house and keep your unscrutanised code all to yourself?

    7. Re:Frameworks by Anonymous Coward · · Score: 0

      Yes. You didn't?!?

    8. Re:Frameworks by GWXerog · · Score: 1

      This is Terry A Davis you CIA n*gger

    9. Re:Frameworks by Anonymous Coward · · Score: 0

      There is a big difference between something like yum, rpm, apt and things like nuget and npm. On yum, rpm, apt the packages are maintained by the distribution maintainers. And, at least for apt, the packages are also signed by the maintainers.
      As for nuget and npm, any idiot can dump their crap on those repositories: there is no validation whatsoever.

  4. This ain't pokemon by Anonymous Coward · · Score: 0

    You aren't going to catch 'em all. These types of public package management systems are going to need a major overhaul with security and auditing in mind. I'm looking at you PyPI!

  5. And that's why we can't have nice things by Anonymous Coward · · Score: 5, Insightful

    As a Dev NOT working with JS and NPM: Given the vast number of packages on NPM https://developers.slashdot.org/story/17/01/14/0222245/nodejss-npm-is-now-the-largest-package-registry-in-the-world I'd wager a pretty penny there are more foul packages out there.
    Dependency managers like Maven, Gradle, NPM, Pipenv and Bundler have made linking against other peoples libraries a walk in the park. Regardless if you draw your packages from public servers or your private Artifactory Server.

    YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.
    They spotted that one on time, but rest assured, there are probably hundreds of other packages out there (not only on NPM) that are either faulty, insecure or downright malicious.

    We should take this as a shot across the bow. Be vigilent and don't rely on the competence of others to sort out the rotten apples for you. Think twice before you include some nifty lib into your project. If in doubt, get the source code (where available) and vet the source you got the binary from. Developers supplying packages should have their packages cryptographically signed for their own protection. It's not like this technology didn't exists. We only don't use it out of convenience and trust me ... the road to hell the most convenient one there is.

    1. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 2, Interesting

      One day I accidently ran "npm install aws-cli" instead of "pip install aws-cli", and ended up finding this little gem:

      https://www.npmjs.com/package/aws-cli

      which at the time had 60k downloads a WEEK, and was some random script that would delete your AWS certs...

      in addition to importing a dependency which installs a backdoor designed by some communist crypto currency secret society:

      https://www.npmjs.com/package/operetta

      just follow the trail and youll get here: http://telekommunisten.net/ ... and that leads to dark places

    2. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 0

      i think its hilarious that this guy doesnt give a shit about his backdoor in npm and nobody does anything about it:

      https://www.npmjs.com/package/operetta

      from page:

      That's right, small and cheap. So far it's only got One Hundred and Seven Lines of Code. So get it while it's small, before I add thousands of lines to support such must-have features as sending and receiving email and impersonating a teenager in IRC channels.

      And yes, I called you Shirley.

    3. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 3, Interesting

      The basic problem is that ANY package may contain something malicious. How in the world can you possibly audit them? Many packages depend upon other packages as well. There is often a whole chain of dependencies. Any single one of those packages could have code injected into them (on purpose or because the maintainer got hacked and submitted a signed package that wasn't really theirs).

      So, the choice is to reinvent the wheel or to accept a certain level of risk. A company with the resources of Apple or Google probably prefers to reinvent. But most companies don't have those resources. It is very expensive to audit (and you would have to audit every single version change).

      I am not suggesting people ignore the problem. One does need to be vigilant, but often the cost/benefit is not there to do a thorough job of vetting.

    4. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 0

      I always enjoy when obvious non-developers try to point out "backdoors".

      The page itself says exactly what it does, which is implement the iam-serverdelcert method that very clearly deletes certificates. I'm not saying it's useful, but if you could lose your AWS certs via this library, you're probably also the type of person that blows his head off with a shotgun while cleaning it.

    5. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 0

      Every bitcoin miner zip executable mining application I've downloaded, always had a virus in it.

    6. Re:And that's why we can't have nice things by skids · · Score: 3, Insightful

      YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.

      Any library can become bogus and malicious at any given time. One compromised laptop and a keystroke logger to get the DSA key+password is all it takes. I don't think many developers would sign up for a system of "if you write code, you have to stick around and watch that code and all its dependencies vigilantly" because you'd have to stop writing code at age 25 and spend the rest of your life on the full-time job of monitoring what you wrote. The point of volunteer OSS is you are supposed to be able to contribute what you are willing to, when you want to.

      Libraries are a double-edged sword security-wise... bugs and compromises in them affect everything, but on the bright side, you only have to fix them in one place, not hunt variants of them down in the thousands. (Not to say that there are not tons of completely redundant libraries due to NIH, megalomania, or just not being aware of other solutions.)

      When you see something like TFA happen you need only ask: what work was too menial for anyone to do on a volunteer bases that this was not caught and then you know what the OSS community needs to find someone to pay someone to do.

    7. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 1

      That project clearly serves no purpose except to typo-squat on a popular project and load a crooked dependency. And it is currently getting over 10k downloads a week RIGHT NOW.

      I always enjoy when someone who clearly has no idea about security tries to point out absolutely nothing of value to anyone.

    8. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 0

      I picked a bad day to stop drinking the koolaid

    9. Re:And that's why we can't have nice things by AuMatar · · Score: 2

      You don't need to audit every change. You freeze a version, and use that until you need to update. You know, like we've been doing for 50 years.

      You also employ layered trust. Is it likely a major open source library, or a library from a major company is safe? Yes. Is some random thing off some guy on github? No. You avoid the second type, trust the first, and audit those in between.

      --
      I still have more fans than freaks. WTF is wrong with you people?
    10. Re:And that's why we can't have nice things by barbariccow · · Score: 1

      You know just installing it doesn't mean you're CALLING it right? Like, you'd literally have to install that package and then call aws-cli.deleteAllMyShit();

    11. Re:And that's why we can't have nice things by squiggleslash · · Score: 2

      YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.

      1. Best practices dictates you should never reinvent the wheel. Someone else, apparently, has done it better than you have somewhere. You should seek them out and use their code.

      2. Best practices dictates you should always keep on top of updates, and ensure that you're always running the latest version of every bit of code you get externally

      3. Apparently you should also know, somehow, that a project you use now contains malicious code.

      Honestly guys, we need a new set of "best practices" because this shit isn't working. We want to program, not be sysadmins for a giant ball of interconnected third party plug-ins.

      --
      You are not alone. This is not normal. None of this is normal.
    12. Re:And that's why we can't have nice things by Anonymous Coward · · Score: 0

      I think they're full of shit. I just downloaded Operetta and checked it out.

      It has no dependencies and doesn't do anything odd. Maybe his keyword scanner set off alarms at "listener" and "bind" in operetta.js, or maybe the examples/examples_nit.js file with its "clone", "commit" and "push" language.

    13. Re: And that's why we can't have nice things by Anonymous Coward · · Score: 0

      It's even worse if you start consider licenses and legal aspects of using others code, in addition to all the security threats and upgrade pains or missing fixes and maintenance. You are wrong, clearly, but won't let mature sysadmins help you help yourself. So we'll watch you burn.

  6. Newly created, popular, and deprecated by iYk6 · · Score: 1

    Newly created, popular, and deprecated. That doesn't sound right.

    1. Re:Newly created, popular, and deprecated by The+Fat+Bastard · · Score: 5, Insightful

      You must not be familiar with JavaScript development. The moment you learn a JS framework, ten more JS frameworks will pop up and your newly learned JS framework will already be depreciated.

    2. Re:Newly created, popular, and deprecated by kaizendojo · · Score: 2, Funny

      That's got to be the first time a misspelling still worked as a valid sentence. Cheers! ;)

  7. A fucking library for cookies? by Anonymous Coward · · Score: 0

    Why the fuck do you need a fucking library for working with fucking cookies? It's built-in fucking vanilla javascript you fucking idiots.

    1. Re:A fucking library for cookies? by Anonymous Coward · · Score: 1

      Because, like everything in Javascript, all the different browsers and all the different versions of the browsers will have quirks, little bugs, different ways of doing things, handle edge cases differently, etc etc etc. So you need a common library to act as an adapter.

    2. Re:A fucking library for cookies? by omnichad · · Score: 1

      Of course, the common library is supposed to be ECMAScript. Regardless, Node is a server-side language and does not deal with browser quirks in that way.

  8. If they didn't need frameworks... by Viol8 · · Score: 0, Flamebait

    ... then they'd be half decent coders and wouldn't be coding in babyscript, sorry, javascript. This language is where idiots and MBAs straight off an "Anyone can code!" course end up, writing Hello World style programs using half a dozen libraries to create a Hello factory and a World factory with another factory that joins factories which then creates a HelloWorld object that eventually outputs a string via some StringOutputter object.

    1. Re: If they didn't need frameworks... by Anonymous Coward · · Score: 0

      Man, I feel you. I have seen that bs so many times...

    2. Re:If they didn't need frameworks... by Anonymous Coward · · Score: 0

      You're describing Java with factories on top of factories, not Javascript. A half decent coder might know there is a difference between the two.

    3. Re:If they didn't need frameworks... by cascadingstylesheet · · Score: 2

      ... then they'd be half decent coders and wouldn't be coding in babyscript, sorry, javascript. This language is where idiots and MBAs straight off an "Anyone can code!" course end up, writing Hello World style programs using half a dozen libraries to create a Hello factory and a World factory with another factory that joins factories which then creates a HelloWorld object that eventually outputs a string via some StringOutputter object.

      You do realize that you are describing Java (or some other "real" language), right? Not JavaScript?

      JavaScript usually only ends up looking like that because someone comes to it thinking "I have to make this more like a "real" language ..."

    4. Re:If they didn't need frameworks... by Anonymous Coward · · Score: 0

      It's the best place to bury something nefarious - hidden inside a deeply nested hierachy of directories combined with misconfigured scripts with subroutine calls jumping all over the place.

      Somebody is always trying something ... either it's people tacking on "extra data" pointers to network packet drivers so the higher level API's don't see the data. Maybe it's a broken routine to detect packets with faulty checksums.

      Then the package maintainers of Linux say "you shouldn't need to have to compile your own applications. Just download and install the precompiled versions straight from the server".

    5. Re:If they didn't need frameworks... by Anonymous Coward · · Score: 0

      * eczema script? Requires tons of extra work to make it less irritating and nasty-looking.

    6. Re:If they didn't need frameworks... by barbariccow · · Score: 1

      I don't understand your last point. Even if you're using gentoo and compiling from source, are you REALLY auditing all the code before you compile it? So... what's the difference? I mean hell, at some point you have to have a pre-packged compiler which could be checking for some routine, like check password, and compiling it differently so even a source code audit wouldn't fix it and you'd have a backdoor into all UNIX systems.

    7. Re:If they didn't need frameworks... by Anonymous Coward · · Score: 0

      Please find and read GoF. Factory patterns aren't exclusive to Java nor Javascript.

    8. Re: If they didn't need frameworks... by Anonymous Coward · · Score: 0

      Decent coders care about code, off hours, where the glory can be beholden and appreciated. How is left as an exercise to the avid reader.

  9. So much JS hate here by Arkham · · Score: 4, Insightful

    I don't personally do any significant JS development, but the suggestion that this is a JS-specific problem is silly. This could have just as well been in a Java or C++ framework. We all use third party libraries and frameworks all the time without doing a line-by-line code review.

    The real story here isn't that someone tried to slip in a backdoor. The story should be about how the NPM team did their due diligence and protected all of their users by catching this. Good job to them.

    --
    - Vincit qui patitur.
    1. Re:So much JS hate here by The+MAZZTer · · Score: 1

      Yup. JS is, if anything, a bit better than other languages since you CAN go through the source code of packages you install. The only thing that keeps it from being better in this regard is that node can have native modules which are binary blobs, and so you won't be able to tell what those are doing, same as libraries you might link to in other languages.

    2. Re:So much JS hate here by TheRaven64 · · Score: 2, Informative

      I don't personally do any significant JS development, but the suggestion that this is a JS-specific problem is silly. This could have just as well been in a Java or C++ framework. We all use third party libraries and frameworks all the time without doing a line-by-line code review.

      There's one difference: when I use a C/C++ library, I almost always install it via my operating system's package manager. The version installed won't have been checked for backdoors, but it will at least be a released version that has gone through some minimal QA. The fact that it's included at all typically means that upstream has a half-competent release process or that some other applications are depending on it and making it worth packaging.

      Newer languages all seem to feel the need to create a per-language package manager. This works fine as long as all software is written in that language, but is really painful for multi-language software (i.e. most non-trivial programs). NPM isn't quite the worst - the default way of including stuff in a Go program is to point at the upstream project's git repo and have your build environment clone the head revision and statically link it into your binary - but it's pretty bad.

      --
      I am TheRaven on Soylent News
    3. Re:So much JS hate here by Anonymous Coward · · Score: 0

      Then you'll run into vendor lock-in of the OS. While it isn't too bad for Ubuntu LTS, good luck when all you have access to is RHEL's legacy offering of packages. Sure they're stable and probably don't have those backdoors, but they severely lack modern features.

  10. This makes me irrationally angry. by Anonymous Coward · · Score: 1, Interesting

    While real programmers working in real languages are getting laid off or outsourced millennial programming languages like javascript and tools like npm get made and get widely distributed around the internet. I hope the whole stack gets wannacried/code reded soon.

    1. Re:This makes me irrationally angry. by Anonymous Coward · · Score: 1
    2. Re:This makes me irrationally angry. by Anonymous Coward · · Score: 0

      I can see the contention with Apache since there really is no reason to use it anymore when alternatives like nginx are easier to configure and more performant. However, anyone still thinking that PHP is terrible hasn't looked at how far it has come in just the last few years alone. Composer and PSR, along with the improvements of PHP 7, have fixed many of its biggest problems

    3. Re:This makes me irrationally angry. by barbariccow · · Score: 1

      Most all products these days are inherited. Sure, if starting a brand new ecosystem with a bunch of interns maybe nodejs is the way to go. maybe.

    4. Re:This makes me irrationally angry. by Anonymous Coward · · Score: 0

      Only extremely trivial programs in NodeJS are faster than a LAMP/LnMP stack. The only benchmarks I've ever seen with regards to NodeJS performance against a traditional network stack are "Hello Wold" type programs. Of course NodeJS is faster in that extremely limited use-case. Duh. But when you want to do REAL work, suddenly that non-blocking nature of NodeJS starts kicking your app's speed in the nuts. Repeatedly. There are multiple reasons why NodeJS is going to crash and burn hard but the inability for NodeJS to be used for anything non-trivial is the main one that will ultimately kill it off. It needed to die at the outset, it'll just take longer since there are still clueless fanboys like you out there who don't understand how hardware architecture is designed.

      PHP revamped one of its critical data structures for PHP 7, making huge performance gains. If you haven't used PHP 7, then you are out of touch with reality.

  11. When you find this person by fredrated · · Score: 0

    break the bones in both their hands.

  12. Easily explained... by Anonymous Coward · · Score: 0

    So they basically linked to Facebook?

  13. Dangers of relying on the Tower of Abstraction by ErichTheRed · · Score: 3, Insightful

    We all know that JavaScript is a pretty messy language to work with unless you're using some sort of framework. Part of that is that it's been pushed to do way more than it ever was designed to do and is hyper-complex as a result.

    I guess my question is how far up the abstraction tower goes. Why would developers pull hundreds of libraries from dozens of sources just to build a simple program? And more importantly, why would you dynamically pull these resources instead of building against a known-good set, and only update one of your dependencies when you've tested it completely?

    I know software is all about move-fast-and-break-things these days, but the "trust the Internet implicitly for all my source packages" is one thing I can't get my head around.

    1. Re:Dangers of relying on the Tower of Abstraction by cyberfunkr · · Score: 1

      We all know that JavaScript is a pretty messy language to work with unless you're using some sort of framework. Part of that is that it's been pushed to do way more than it ever was designed to do and is hyper-complex as a result.

      I guess my question is how far up the abstraction tower goes. Why would developers pull hundreds of libraries from dozens of sources just to build a simple program? And more importantly, why would you dynamically pull these resources instead of building against a known-good set, and only update one of your dependencies when you've tested it completely?

      I know software is all about move-fast-and-break-things these days, but the "trust the Internet implicitly for all my source packages" is one thing I can't get my head around.

      THIS! A thousand times this.

      Seems like no one knows how to actually write code any more, they just know how to tape together a bunch of other peoples snippets.

    2. Re:Dangers of relying on the Tower of Abstraction by Anonymous Coward · · Score: 0

      why isn't that comment modded up to a 5+ ...and it's parent too!

    3. Re:Dangers of relying on the Tower of Abstraction by Anonymous Coward · · Score: 0

      Why reinvent the wheel when someone else has already done it and shared it for free? Sure, review the code to be sure it's doing what it is supposed to do (and nothing else), especially if it's mission critical or deals with sensitive data. Most of the projects out there that use Node.js don't meet this threshold.

    4. Re:Dangers of relying on the Tower of Abstraction by Anonymous Coward · · Score: 0

      it's a side-effect of minimalism. Out-of-the-box, javascript is a pretty simple language without a massive standard library the way java, for example, has. So, to do something useful with it, you either roll your own or you take advantage of the pain someone else has gone through to build libraries to do common (and not-so-common) tasks. Apparently ECMAscript (because fuck Oracle) will soon have one, but that's still upcoming. It seems to have gone quite a bit overboard and the frameworks get.. tiresome. But, with node it seems to be able to be more seemingly minimal. Instead of a huge, say, Rails like system, you just go with Node and Express and build from there. Don't use an ORM? don't install one, that kinda thing. Sure, there's a ton of shit layered on top, kinda needed, but you'll have that in C/C++ etc for a webserver, as well.

      As for why dynamically pull those resources: most production servers don't, or at least they shouldn't. Just google the solutions people use to cache versions of various packages to prevent exactly that kind of thing from happening. Just like you'd probably not sudo apt-get dist-upgrade on a production server for shits and giggles, you'd also not do the same on a production node install. At least if you want to be employed for very long. (caveat: if you're the boss, fuck it, let's do it in prod).

    5. Re:Dangers of relying on the Tower of Abstraction by barbariccow · · Score: 1

      If you don't need to support IE 5, 6, 7, or 8 (which thankfully are falling out of favour), there's really no need to have heavy abstraction libraries. They just make things slow and complicated and dependant on 3rd party. For years I've had a 150 line JS script with stuff like "get parent element of passed element containing passed class name" and it handles everything splendidly. It's not hard if you understand how the DOM works, you're almost just working within XML, which is another lost art...

    6. Re:Dangers of relying on the Tower of Abstraction by Anonymous Coward · · Score: 0

      I'd give you all my karma for this, but I'm a Coward.

    7. Re:Dangers of relying on the Tower of Abstraction by omnichad · · Score: 1

      Please, don't call XML anything to do with art. Unless you're a Tolkien fan, I guess.

    8. Re:Dangers of relying on the Tower of Abstraction by Zontar+The+Mindless · · Score: 1

      If you don't understand that there really are suitable use cases for DOM/XML, then please don't comment on them.

      (Hint: What does the "D" in "DOM" stand for?)

      --
      Il n'y a pas de Planet B.
  14. The news isn't that someone tried it by Anonymous Coward · · Score: 1

    It's that it was detected and prevented. How many backdoors are in there that went undetected?

    1. Re:The news isn't that someone tried it by Anonymous Coward · · Score: 0

      42

  15. Re:Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    Dude, no one knows who Zontar is. Also, no one cares. At least confine your petty spats to replies to his posts, like you used to do.

  16. Re:Zontar starts w/ me I finish it (see ps) by Zontar+The+Mindless · · Score: 1

    After (I think) 3 years, APK is still rankled that I really was able to track him down.

    (And I do admit to feeling just a teeny-tiny bit of a warm glow every time he whinges about it.)

    BTW, all the postcard said was, "Greetings from Stockholm. Behave yourself. Regards, Z."

    --
    Il n'y a pas de Planet B.
  17. Re:Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    Zontar is a 10,000-year-old Sumerian wizard who's been reading Slashdot since it was published on clay tablets.

  18. Re:Zontar starts w/ me I finish it (see ps) by thegreatbob · · Score: 2

    I let him crash on my couch at one point, and now he won't leave.

    --
    There is no XUL, only WebExtensions...
  19. Re:Zontar starts w/ me I finish it (see ps) by thegreatbob · · Score: 1

    Also possible we're not talking about the same Zontar.

    --
    There is no XUL, only WebExtensions...
  20. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  21. Re: Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    Ugh, dealing with APK like that is an ugly trap. I got sucked in by him once years ago, answering every one of his posts on the thread and wasting a huge amount of time (and mental health). I ended up tracking down Alexander's name and address. I even e-mailed one of his former employers (shocked that he could have even had one). They said that yes, he had worked for them but would not give other details. At the time, I let myself get pulled in. I was just so angry about all of his insults and transparent posts from fake "supporters", etc.
    Today, I just feel dirty about the whole thing. It was pointless, and it''s scary how easy it is to get dragged down to that level.
    Interestingly, I've ctually had some conversations with him on Slashdot that wereally on topic and coherent without any acrimony. I even managed to correct him on a misapprehension he had about a technology, and we discussed it calmly and rationally and he made his point and I made mine and no-one had to stalk anyone or anything.

  22. Re:Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    If you're being telepathically restrained from kicking him out, then, yeah, that's him.

  23. Re: Zontar starts w/ me I finish it (see ps) by Zontar+The+Mindless · · Score: 1

    Yeah, he tries really hard to do the Tar Baby thing, and usually I just ignore him.

    But the bit about *threatening* him via the mails is completely false.

    --
    Il n'y a pas de Planet B.
  24. Jail Time by Anonymous Coward · · Score: 0

    There should be some kind of verification system for anyone posting downloadable code and/or attempting to subvert existing projects. This kind of code must be tracked and the people (or organization(s)) responsible must see jail time.

  25. Re: Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    But the bit about *threatening* him via the mails is completely false.

    I don't know the details of your particular situation but I'm inclined to believe you given what I know of APcucK. He starts with a tiny bit of truth (and a whole lot of nonsense), and after a few posts has reality so twisted around that nobody knows whats true any more. APK is a manipulative weasel that I've squashed many times.

    For most people on /. I'd recommend against replying to anything APK posts. He'll suck you into his world, and you won't fair well if you're not prepared to wrestle and defeat someone with mental illness.

    Mods: keep up with downmods of APK. He probably won't ever give up, but burying his spam coward posts is what he deserves and it is best for /.

    ZIP

    P.S. => nice to meet you. I've been accused of being you several times because APK can only obsess about one person at a time.

  26. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  27. Re: Zontar starts w/ me I finish it (see ps) by Anonymous Coward · · Score: 0

    Zontar you conveniently avoid you admit you sockpuppet troll and downmod bomb apk. Why did you avoid all that?

  28. Re: Zontar starts w/ me I finish it (see ps) by Zontar+The+Mindless · · Score: 1

    This is the only Slashdot account that I have.

    And I don't need to waste mod points on you--your crap is almost always modded down by the time I see it, in any case.

    And why do you insist on talking about yourself in the 3rd person? You think no-one can tell, do you?

    Meanwhile, you keep right on modding my 5 most recent posts as Offtopic or Overrated whenever one of your sockpuppets gets mod points, if it really makes you feel better.

    --
    Il n'y a pas de Planet B.
  29. Re:Zontar meet me face to face... apk by Anonymous Coward · · Score: 0

    What the fuck is wrong with you?

  30. Re:Zontar starts w/ me I finish it (see ps) by thegreatbob · · Score: 1

    Confirmed. I tried again last night, and came back to consciousness today singing a song in a tongue I did not know, but understanding that it was in his praise.

    --
    There is no XUL, only WebExtensions...