Ruby gems are still not safe to use • Hacker News Board

Re: Ruby gems are still not safe to use

#41

Post by slurgfest » Sat, Feb 02, 2013, 9:21 PM UTC

Xylakant wrote: post #29

PommeDeTerre wrote: post #21

Earlier quoted context omitted.

Your name-calling aside, how do you propose that the Ruby community deal with these inherent problems with their software and their attitudes? Will they do the responsible thing and throw out all of the existing, poorly-written code? Will they collectively ditch RubyGems in favor of a system that has some modicum of security built in from the start? Will they throw out their flawed development philosophies, so that t…

Ok, serious question: In which ways is rubygems less safe than .deb packages, .rpms, portfiles or ebuilds, python eggs, jars or composer files? All of those are mechanisms to distribute and deploy code. All of those suffer from the same basic vulnerability: They ship code that gets executed. If that code gets compromised, you have a viable attack. Debian saw its developer repositories compromised at least in 2006 [1]…

Without disagreeing with you substantively, Python eggs have not been the main way Python packages are distributed for years now. This is not to say that PyPI couldn't use some attention to issues like signing!

Re: Ruby gems are still not safe to use

#42

Post by static_typed » Sat, Feb 02, 2013, 9:26 PM UTC

ef4 wrote: post #38

Worrying about code execution at install is silly. The whole point of installing a gem is to download code that you're going to execute. So the whole gem (install code and runtime code) needs to be trusted, and should be verifiably signed by somebody you can trust.

I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems.

Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but what about when he pulls in a dependency, that pulls in another dependency, and suddenly you have gems from developer B, who loves to stick a Yaml parser out there for all to compromise.

The whole design needs a rethink.

Re: Ruby gems are still not safe to use

#43

Post by slurgfest » Sat, Feb 02, 2013, 9:31 PM UTC

BSousa wrote: post #16

PommeDeTerre wrote: post #13

Earlier quoted context omitted.

Another approach is to completely move away from using Ruby, Ruby on Rails and related software. I think that the recent security issues are evidence of many systemic problems within the Ruby community, and with their approach and attitude toward software development. Security should be inherent and considered from the very start, rather than brought on over time by an endless stream of patches and updates. Furthermo…

Do you suggest an alternative? That works on Mac/Linux. Is Python/Django that much secure or just not targeted enough? I'm evaluating languages/frameworks for a project and I really want to use Haskell and yesod or happstack, but after starting my project in them, I always end up going back to Rails for the documentation/ease. I may try and stick to it this time but any suggestions would be great.

Much as I prefer Python, I don't think that switching to it just for more security is going to be very satisfying or have a huge return.

I submit that security is typically more a function of your project than JUST the language it is written in. For example, I doubt that Haskell's focus on type safety alone will make your programs secure (particularly when you are not enjoying it and are spending more time than you want on issues other than security). You may get more bang for the buck by focusing on security as an issue within whatever language you are using?

Re: Ruby gems are still not safe to use

#44

Post by slurgfest » Sat, Feb 02, 2013, 9:52 PM UTC

PommeDeTerre wrote: post #17

phillc wrote: post #15

Earlier quoted context omitted.

Your philosophies are sound for banking software. There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.

That's a very dangerous attitude to have. Security is not something that should be traded off just to reduce development time or effort slightly. Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing pr…

Consider physical security against terrorist attacks. You can spend unlimited resources trying to prevent these. But this is subject to diminishing returns, and has other costs.In software projects, too, there IS a point at which it is more rational to trade off security against something else.

I would argue that the situation with Rails is analogous to the (historical) situation with Windows. There have been some design mistakes which have opened up more surface area for attacks. But the number of exploits has a lot more to do with market share.

Re: Ruby gems are still not safe to use

#45

Post by Xylakant » Sun, Feb 03, 2013, 10:36 AM UTC

static_typed wrote: post #42

ef4 wrote: post #38

Worrying about code execution at install is silly. The whole point of installing a gem is to download code that you're going to execute. So the whole gem (install code and runtime code) needs to be trusted, and should be verifiably signed by somebody you can trust.

I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems. Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but what about when he pulls in a dependency, that pulls in another dependency, and suddenly you have gems from developer B, who loves to stick a Yaml parser out there for all to compromi…

But isn't that a problem where no good solutions exist? We share code to reuse code. If we insist to allow only one level of dependencies, then we restrict code reuse which is bad in other ways: you promote reimplementation of functionality, more often bad than good.