[ruby-core:52280] [ruby-trunk - Feature #7854] New method Symbol[string]

Issue #7854 has been updated by Student (Nathan Zook).


=begin
Ticket #7839 requires the manipulation of global state.  I'm not sure why I have to explain that this is a REALLY bad idea.

Ticket #7791 has two possible implementations.  One is to GC symbols globally.  This would require treating not just symbols like objects, but methods (whose names are in fact symbols) as well.  I do not believe that methods are even currently part of the object system.

Another implementation would be to divide symbols into two kinds depending on how they are created.  The theory being that symbols used for method names would be immune to GC.  The first problem with this is that there is no reason to believe that method declarations are the first place that a particular symbol would be declared.  The second is that dynamic method creation is an important part of ruby.  If the goal is to protect against memory leaks in this fashion, it is not at all certain that the leak does not extend into the realm of method creation.

In other words, both of these implementations involve complex changes to the guts of Ruby, and lead to the likelihood of a significant behavioural fork with other rubys.  (Not to mention the relatively high risk of bug introduction.)  Since this is a security feature, I think that it is important to lead the way in a direction that is easy to import to other rubies (and also to backport as a security patch!)  I expect Symbol[] to have a very straightforward implementation that is well-isolated from the rest of Ruby, with the possible exception of YAML.*load*, which might well benefit from such a feature.

As for requiring the libraries to all be updated to make use of this feature--I consider that to be a good thing.  #7839 creates a change in MRI's behaviour that WILL break apparently "safe" use of existing libraries.  #7791 necessarily dramatically affects Symbol's runtime performance, and thus means that any highly-tuned ruby is going to have issues--assuming that no bugs occur, and that the other rubys pick it up.

Furthermore, for most, perhaps even all, libraries, (({grep -R to_sym lib})) is going to tell you what you need to examine to make use of this feature.  Certainly, it would be nice to avoid having to do such things, but because of the recent exploits, the more security-minded portion of the community (such as myself) is ALREADY nervously poking around in their libraries.

This feature gives the community a clean way to patch questionable code, which is itself relatively easy to identify in manner that makes it easy for other rubies to quickly follow.  I do not believe that the other proposals do.
=end
----------------------------------------
Feature #7854: New method Symbol[string]
https://bugs.ruby-lang.org/issues/7854#change-36307

Author: Student (Nathan Zook)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: next minor


I propose a new class method [] on Symbol.  If a symbol s already exists such that s.to_s == string, then s is returned.  If not, nil is returned.

The inspiration for this method is a question I was asked, and the answer I was given:  "Why would you want to turn a tainted string into a symbol?"  "I don't--I want to access an existing symbol with tainted data".  Symbol[] accesses the symbol table like hash[] accesses the elements of a hash.

I believe that this completely addresses the problems behind tickets #7791 and #7839.  I believe that it is a more intuitive solution than my proposal #7795, and I believe that this will also be useful for YAML.safe_load and similar initiatives.



-- 
http://bugs.ruby-lang.org/