From: vasilakisfil@... Date: 2018-01-08T12:40:21+00:00 Subject: [ruby-core:84708] [Ruby trunk Feature#14337] We need add primitives in Ruby that help us compartmentalizing specific parts of our code (with guarantees) Issue #14337 has been updated by vasilakisfil (Filippos Vasilakis). dsferreira (Daniel Ferreira) wrote: > Ruby was not meant to be handled like that. > Security should be handled in different ways. > If you���re concerned about the security of your app, and you should, you should work with ruby core directly and use only ruby gems in which you can trust due to wide spread use by the community. > Otherwise you should audit the gems yourself. > These security problems always existed in ruby and you have a countless number of applications (e.g. Github) in the wild using ruby. > If you use ruby you should obey ruby philosophy. > In ruby almost everything is allowed. > ���With great power comes great responsability��� I don't agree with that, mostly because what I am suggesting is a backwards-compatible extension to the Ruby model what would increase security significally, on demand. Of course I check the gems I add and the gems those gems use, but that gives me no guarantees at all. What I want is guarantees. Even an advanced/expert Ruby developer could be easily tricked with the current model and there is no question to that that there is nothing you can do about it. ---------------------------------------- Feature #14337: We need add primitives in Ruby that help us compartmentalizing specific parts of our code (with guarantees) https://bugs.ruby-lang.org/issues/14337#change-69428 * Author: vasilakisfil (Filippos Vasilakis) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- With the recent incidents in the npm community (https://github.com/npm/registry/issues/255), the earlier the unethical moves of Kite (https://theoutline.com/post/1953/how-a-vc-funded-company-is-undermining-the-open-source-community), the fact that a maintainer of a popular gem can publish a new version in Rubygems without publishing anything in Github, or that the maintainer can bump and publish a new version in Github but still send different code in Rubygems, from which people download the gem, it feels that we need to put some thinking on security features of Ruby. It feels like any ruby gem that I include in my Ruby app can access the db credentials and can do pretty much anything (even overriding methods) because in Ruby you can access everything even unexposed instance variables. We need to add primitives in Ruby (although I suspect that other languages like PHP, Elixir and Javascript probably have the same issues) that help us compartmentalizing specific parts of our code. freeze method implemented in the language itself is a good start. When you freeze a constant, you make it immutable and thus cannot be changed by any means. We need more primitives like that. We need ways to say that this class cannot be extended/reopened/altered by default. The same goes with methods, we need to give ways to developers to not allow critical methods to be altered. We need to instruct constants that are not supposed to be accessible by outside as private only by explicitly marking them as private (it needs some special work). Or be able to instruct Ruby to not expose any information regarding a class/instance, like instance variables etc. Because a lot of confidential data sit there. Once we do that, then the application frameworks need to use those primitives but also build upon those. For instance, in Rails, critical (if not all) classes/methods/constants should not only be ���frozen��� (which means cannot be modified by malicious code) but also be declared as private-only so that installed gems don���t even have access to such information by default. Let the user inject what she thinks that is necessary for her installed gem to work, through the initializers. Classes should not be open for extension by default, unless the user instructs differently (that could be a bit challenging). It might take some time and effort but we need to invest time and find better ways on how to protect ourselves from such and similar attacks. What do you think folks, would it be something that you would consider ? -- https://bugs.ruby-lang.org/ Unsubscribe: