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


Creating global state has global implications.  Yes, there are threading implications.  Yes, there are issues with called libraries.  But what really annoys me is yet again some software providers (again from the Rails team) that thinks he understands everything that users of his software might do.  

I'm NOT just talking about poorly designed code.  Honestly, I think that normal Rails behaviour is not expected to match this.  I know that dynamic finders are supposed to be passe', but if Rails continues to implement ANY dynamic method generation that happens at runtime, then there is no way to know when the particular piece of code that does the generation gets called.  In fact, this entire conversation got started because the Rails framework intentionally generated symbols during runtime.  That's not to mention (Rails) application code doing so for perfectly reasonable conditions.

I very much favour making the symbol table queriable. (#7795)  Let YAML.safe_load check it.  Let to_json(:safe => true) check it.  But don't break existing code simply because you think your global solution is going to make life good for everyone.



----------------------------------------
Feature #7839: Symbol.freeze_symbols
https://bugs.ruby-lang.org/issues/7839#change-36195

Author: tenderlovemaking (Aaron Patterson)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Hi,

On team Rails, we're having troubles with Symbol creation DoS attacks.  From our perspective, there should be a point in the application where symbols should stabilize, meaning we don't expect the number of symbols to increase while the process is running.

I'd like to be able to call a method like `Symbol.freeze_symbols` which would essentially freeze the symbol hash, such that if any new symbols are created, an exception would be thrown.

I can work on a patch for this, but I wanted to throw the idea out there.


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