From: hanmac@... Date: 2018-01-08T14:50:23+00:00 Subject: [ruby-core:84717] [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 Hanmac (Hans Mackowiak). also about ruby gems: you can push the C-Lib gems as source but also as precompiled ones (for ones without compiler) now if you don't have add an repository, or even if the code is different, you can't trust the precompiled C-Lib gem. i for myself does not prefer them, because the things i did are build exactly to the system it's build on also even i use github and its feature as OAUTH service to login somewhere else, i would not like it if it's required for ruby ---------------------------------------- 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-69437 * 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: