back to article No REST for the wicked: Ruby gem hacked to siphon passwords, secrets from web devs

An old version of a Ruby software package called rest-client that was modified and released about a week ago has been removed from the Ruby Gems repository – because it was found to be deliberately leaking victims' credentials to a remote server. Jussi Koljonen, a developer with Visma in Helsinki, Finland, discovered the …

  1. Nick Kew Silver badge

    Lessons

    Compromised old developer account: hmmm, perhaps something to learn lessons from. Expire inactive devs, or at least require a cryptographically secure reactivation of an account?

    About a week trojan lifetime: nasty, but at least it was limited. You didn't tell us whether the dev who discovered it is himself a member of that particular dev team, and thus would've seen it even if it hadn't been open source.

  2. mj.jam

    Review changes to 3rd party code

    Once again the blindly pulling of third party code causes problems.

    The only way to stay secure is to specify a version, and audit all changes.

    With Javascript, either use a local copy, or use SRI (or if you are BA, do both)

    If building into your own code, then fix the versions, and check and changes.

    1. karlkarl Bronze badge

      Re: Review changes to 3rd party code

      Ugh I hate this amateur "web dev" culture of dragging in dependencies from these library "app stores".

      It feels so careless, non-deterministic, non-futureproof.

      What have we got now?

      NPM

      PIP

      Ruby Gems

      CPAN

      All a dependency nightmare

      Can't web developers just create libraries like proper developers; and manage them in the project. Its not like updates to dependencies don't need to be tested for production anyway; so it might as well just be a case of extracting the new version in place of the old version and test.

      Or do web developers just love all this automation and pulling of data and big dependencies? Does it simply make them tingle inside? ;)

      1. mj.jam
        FAIL

        Re: Review changes to 3rd party code

        The problem is that people don't want to re-invent the wheel constantly. So reusing somebody else's code makes it simple to build things on top of other components.

        The problem comes that people don't review what they are importing, the repositories have no quality control so act as dumping grounds, and then people blindly take updates.

        Also people create pointless components that aren't worth using. For example the wonderful is-even:

        https://www.npmjs.com/package/is-even

        1. Joseph Haig

          Re: Review changes to 3rd party code

          https://www.npmjs.com/package/is-even

          Thanks! This is just what I've been looking for!

        2. MOH

          Re: Review changes to 3rd party code

          51000 weekly downloads ....

        3. John70

          Re: Review changes to 3rd party code

          Don't forget that it's dependant on is-odd to work which in turn is dependant on is-number.

          1. Jimmy2Cows Silver badge
            Facepalm

            Re: Review changes to 3rd party code

            I can understand the need for is-number as a necessary part of string content validation, but is-even and is-odd are just taking the piss. Unnecessary bloat; pointless functions added for the sake of it. AFAIC anyone needing a library function to determine numeric eveness/oddness has no business being a software dev. I certainly wouldn't hire them.

        4. Orv Silver badge

          Re: Review changes to 3rd party code

          Realistically, people who copy in libraries instead of using a tool probably aren't reviewing them either. I use the Forge TLS library in one of my projects. The version I currently have in my source tree is 32,222 lines of Javascript (un-minified). I have neither the time nor the cryptography knowledge to review that.

          These discussions always make me think of the time a major code execution flaw was found in zlib. Applications that took the "lazy" way out and linked to zlib were easily patched just by upgrading zlib. But a lot of other packages had gone to the trouble of copying just the parts of zlib's source code they needed, and compiling it in. Tracking down and patching all of those was much more time consuming.

      2. Anonymous Coward
        Anonymous Coward

        Re: Review changes to 3rd party code

        I tend to agree, however, the culture has been created around the constant desire by clients to pay less and take delivery sooner.

        Not only that the old way of thinking that "fast means good" still persists...gotta get them whizz kids in.

        More importantly, I've always considered Ruby, Node and their ilk to be pure garbage...they're not very well maintained and their package / dependency management is fucking shit.

        Pythons pip system comes pretty close to being shit as well.

        The only dependency management system I've had zero problems with is composer. Probably because the underlying technology is robust and well thought out. Which is probably because the asylum isn't being run by the neckbeards cosplaying as lumberjacks.

        1. Anonymous Coward
          Anonymous Coward

          Re: Review changes to 3rd party code

          the asylum isn't being run by the neckbeards cosplaying as lumberjacks.

          What? Do you understand remotely what you are talking about? Composer is clearly based on NPM (composer.json is package.json, composer.lock is package.json.lock), and from browsing packagist, seems to have as many shit code as any other package repository that anyone can publish to.

          Python's packaging is actually excellent, from old, bad tools like easy_install, pip is an excellent installer (do 1 thing), and there are interesting package dependency management tools like pipenv and poetry.

          Similarly, npm is not good at package dependency management, which is why no-one really uses it now - they use yarn.

          Really, with any language, how you get the packages isn't really relevant. npm, pipenv, poetry, yarn, composer all fetch packages from the net and include them in your project, so what you're really should be interested in is whose code am I using and how much do I trust them. Languages which have high use, in multiple spheres, tend to have higher quality packages. I'd rather use Kenneth Reitz's requests than I would some PHP clone.

          Note that I'm not saying PHP is shit*, but that because it is a language only used by people who slap together websites, it cannot compare (in ecosystem quality) to a general purpose language like Python, that is used for web shit, big data, sysops... basically everything.

          * That happens here. PHP is shit.

      3. dbuxo

        Re: Review changes to 3rd party code

        You only need to build any open source node.js project to be presented with hundred of npm packages downloads every one from one dev or dev group. Many of them with warning texts of the package being deprecated, not updated and not secure.

        Its not possible to get back to the old-school big code libraries, where you only needed 3 or 4 of them to build anything?

    2. sum_of_squares

      Re: Review changes to 3rd party code

      Dev time is money. Also for web development it's not uncommon that the people who build something are also the maintainers later on. If your website goes down, who-you-re-gonna-call? Ghostb.. ..err, the web devs!

      So imagine you have a website portfolio of something like 20+ domains. Would you check every update? For every library? Free of charge? For years?

      Nah, that's an upstream job.

      We have to make sure the repos aren't compromised, not mistrust something like RubyGems.

      Of course we sholld to be picky about which libraries we actually use (or need) in the first place, but that's a different story.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019