Issue #14337 has been updated by vasilakisfil (Filippos Vasilakis).


I never said that Github is required for Rubygems, I was referring to a common practice. Even if I audit the code in my own machine (nothing to do with Github), who can guarantee me that when the gems that are fetched on production from Rubygems, the maintainer of a misbehaved gem won't push a custom version ?

From what I understand your point is: security is very difficult to achieve even on Kernel/Linux level, so we won't add primities to Ruby that could enhance security.

I don't think I agree with that. Although I understand that security is a hard thing to achieve, enhancements wouldn't hurt, given that are backwards compatible with existing codebases and allows the developer to choose if she wants them or not. It's very different to implement a simple Ruby gem that extracts db passwords from targeted Ruby classes, and creating a C lib that exploits a Kernel vulnerability.

----------------------------------------
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-69440

* 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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>