101–110 of 133 posts
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.
If "this could go way deeper" is your answer to a super unpopular rubygem getting hijacked, why isn't that just the default assumption then?
Do you only use thoroughly audited software projects? How do you manage that?
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.
The lack of funding for foundational parts of many popular ecosystems (e.g. NPM, PyPI, Rubygems) never ceases to surprise me.
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.
I know this is about ruby, but it's worth noting that this kind of thing would be solved by effect systems, e.g. Haskell's IO type. If IO isn't part of the signature, you know it's cpu only. Furthermore, you can get more specific such as having a DB type to indicate some code only has access to databases rather than the internet as a whole.
While that might be true, you are not going to switch the world to program in Haskell. We need a solution which also works for most used languages, JS/C++/Java/Python..., which suggests that it should be done at a higher level, maybe with OS involvement somehow.
Earlier quoted context omitted.
Or: 4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.
Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...
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?
> But if you had the key cached, and it changed, you’d probably freak out. Not in the servers-as-cattle age. By default, a rebuilt server will have a new key. Otherwise, you'd have to save the server SSH key in your configuration/build files, and then you've moved what you have to protect to the source control of the servers, and probably exposed that secret key to many more people and developers than you would have…
Earlier quoted context omitted.
Just as an experiment, I want everyone on this thread to think back to the last time you connected over SSH to a new computer on a company network. Did you check to make sure that the key that popped up was correct, or did you just hit accept? This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. Devs will still have their keys compromised, users will still ignore…
>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?
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 about it when they saw the warning.
And I'm literally right there -- they're not going to file a Github issue for a developer they've never met asking why the key changed and then stop working until they get a response.
To push the point even more, how many people on here actually wrote down the SSH fingerprint that they got the first time they connected to a remote machine? When you got a new laptop, did you transfer the keys over, or did you just blindly reconnect to every VM again?
Package managers are meant to help you manage installs on multiple machine, so it's not just the first time you use a package -- it's every time you do a fresh clone the repository, it's every time you throw away your cache and do a new reinstall over the network.
And it's based on this idea that even when doing an update, package managers and developers won't just blindly hit OK if they get a notification that a key changed, which I just don't think is the norm, even in technical circles.
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.
The unanswered question is still how this `kickball` account gained control of the gem. > The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019. The way I see it, there are a few options: 1. The rubygem was transferred by ruby staff to this account. 2. The maintainer's account was hijacked and then it was transfe…
My bet goes to #3. After [0]this commit, everything is possible in Ruby world. [0] https://github.com/rails/rails/commit/b83965785db1eec019edf1...
Earlier quoted context omitted.
My bet goes to #3. After [0]this commit, everything is possible in Ruby world. [0] https://github.com/rails/rails/commit/b83965785db1eec019edf1...
That seems to demonstrate a github vulnerability, rather than anything ruby-specific?