111–120 of 133 posts
Earlier quoted context omitted.
Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.
Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.
Earlier quoted context omitted.
Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.
Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems? The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
If the goal of the project is adoption than do not ignore that group.
Earlier quoted context omitted.
>Did you check to make sure that the key that popped up was correct, or did you just hit accept? But if you had the key cached, and it changed, you’d probably freak out. >This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. You’ve just isolated the impact of these attacks to new installs, how is that not significant?
Okay, followup question -- when was the last time anyone saw the key change and actually did freak out? If you're using VMs, keys change all the time. Maybe some people here are good about security and would freak out, but I'm thinking about workplaces I've been at, and that's not a typical attitude for developers that I know. If I set up a VM at work and changed the keys on it, I doubt my coworkers would even ask me…
Less than a week ago, a server of mine rebooted due to an unannounced power outage. This particular server just stores some backups and didn’t have proper monitoring, I didn’t know it had rebooted. Normally mere unannounced power outages have me shitting bricks, switching hosts or at least extensively verifying the pre-boot environment.
Trying to SSH into the box I received the host key mismatch error because the server boots into dropbear for LUKS. It took me a few minutes to figure out what had happened, but until I did, I definitely fully assumed that my host was up to something really bad.
As already hypothesized in the comments I'm pretty sure this was a simple account hijack. The kickball user likely cracked an old password of mine from before I was using 1password that was leaked from who knows which of the various breaches that have occurred over the years.
I released that gem years ago and barely remembered even having a rubygems account since I'm not doing much OSS work these days. I simply forgot to rotate out that old password there as a result which is definitely my bad.
Since being notified and regaining ownership of the gem I've:
1. Removed the kickball gem owner. I don't know why rubygems did not do this automatically but they did not.
2. Reset to a new strong password specific to rubygems.org (haha) with 1password and secured my account with MFA.
3. Released a new version 0.0.8 of the gem so that anyone that unfortunately installed the bogus/yanked 0.0.7 version will hopefully update to the new/real version of the gem.
Earlier quoted context omitted.
Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems? The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
We've heard this before. Yes. Developers using this may decide not to use this gem. Ruby gems in general may lose trust. If the goal of the project is adoption than do not ignore that group.
as to losing adoption, that would only happen if
a) there were other options with better security, and given that npm, PyPI and others have had similar problems, there probably aren't
b) Developers would actually move ecosystem due to package manager weaknesses. given that hasn't happened with any of the previous instances of supply chain attacks (and this has been going on for 5+ years now) I don't think so.
As one example, rubygems was compromised in 2013 https://news.ycombinator.com/item?id=5139583 did you or anyone else stop using it as a result?
Rubygem should contract an external auditor (security firm), this could go way deeper. Until they perform a throughout audit I will personally stay away from this project.
Earlier quoted context omitted.
Do you feel that anyone in the community who isn't contributing financially or with their time to the project should expect to be able to "demand" anything from Ruby gems? The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
rubygems is actually given some funding by Ruby Together, I'm not sure with what current budget. https://rubytogether.org/
Earlier quoted context omitted.
rubygems is actually given some funding by Ruby Together, I'm not sure with what current budget. https://rubytogether.org/
based on their home page they're somewhere near the lower end of the $20k-$35k category for all funding...
This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers. The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected…
Good analysis, but I'm not sure about "a large number of downloads". Download counts can be pretty inflated due to CI/deployment processes that reinstall gems from scratch repeatedly. I've seen open-sourced gems that never got any real usage outside their original company get that number of downloads. To add a bit of a sense of scale here, the popular Devise gem that's used for authentication in many Rails apps has 5…
This was caught because the author diligently checked their dependencies line by line. How many ruby devs do that?
How many other gems are already hijacked but haven't been discovered because no-one has audited them? That number is almost certainly non-zero.
This is on Rubygems.org. They have enough information to warn devs that the gem might be infected (months since the maintainer logged in, gem version release without github repo changes, maintainer email on haveIbeenpwned and no password change since that date, etc).
We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.