-
-
Notifications
You must be signed in to change notification settings - Fork 932
Quick stab and limited profile runtime #8893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This was quickest and minimal needed to work to get a profile which can load a Ruby runtime. It is not really correct and is meant as a starting point. There are some obvious problems with profile as it is defined. Basic fundamental things like primal Exception types need to be loaded. Allowing people to omit them is a footgun. There is obvious issues with ommitting jruby/kernel. Some of that is required but at the same time it likely hits profile excluded types. Regex is a major source of DOS so it must be excludable but at the same time I suspect we call it many places internally. Methods which use types which are excludable (like Regexp) probably should be aware of excluded types and not bind. This would be a MAJOR amount of work but it would fit into idea of a dependency graph. Likewise we could make a much smarter type declaration where something like: ```java return defineClass(context, "Integer", Numeric, NOT_ALLOCATABLE_ALLOCATOR). reifiedClass(RubyInteger.class). kindOf(new RubyModule.JavaClassKindOf(RubyInteger.class)). classIndex(ClassIndex.INTEGER). defineMethods(context, RubyInteger.class). tap(c-> c.singletonClass(context).undefMethods(context, "new")); ``` (we are only pretending with this example as Integer is too primal to Ruby to be allowed to be excluded) we would want to add something to this which would know that it cannot defineClass unless "Numeric" has been defined. ```java return requires("Numeric", "Fixnum", "Bignum"). defineClass(context, "Integer", Numeric, NOT_ALLOCATABLE_ALLOCATOR). reifiedClass(RubyInteger.class). kindOf(new RubyModule.JavaClassKindOf(RubyInteger.class)). classIndex(ClassIndex.INTEGER). defineMethods(context, RubyInteger.class). tap(c-> c.singletonClass(context).undefMethods(context, "new")); ``` This would end up simplifying the smattering of if's in Ruby to just declare these dependencies in the setup method for the type.
assertEquals(result, "uri:" + url); | ||
} | ||
|
||
class CustomProfile implements Profile { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe call it RestrictedProfile
to match the name the test has?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NinekoTheCat sure. I can change this name in the test. Ultimately this class may get very small as we continue.
This moves IO-related Kernel methods to a separate interface which can be enabled or disabled independently of the rest of Kernel. This relates to recent discussions about making JRuby safely embeddable with only specific classes and features loaded. See other work in jruby#8893
This moves IO-related Kernel methods to a separate interface which can be enabled or disabled independently of the rest of Kernel. This relates to recent discussions about making JRuby safely embeddable with only specific classes and features loaded. See other work in jruby#8893
This was quickest and minimal needed to work to get a profile which can load a Ruby runtime. It is not really correct and is meant as a starting point.
There are some obvious problems with profile as it is defined. Basic fundamental things like primal Exception types need to be loaded. Allowing people to omit them is a footgun.
There is obvious issues with ommitting jruby/kernel. Some of that is required but at the same time it likely hits profile excluded types.
Regex is a major source of DOS so it must be excludable but at the same time I suspect we call it many places internally.
Methods which use types which are excludable (like Regexp) probably should be aware of excluded types and not bind. This would be a MAJOR amount of work but it would fit into idea of a dependency graph. Likewise we could make a much smarter type declaration where something like:
(we are only pretending with this example as Integer is too primal to Ruby to be allowed to be excluded) we would want to add something to this which would know that it cannot defineClass unless "Numeric" has been defined.
This would end up simplifying the smattering of if's in Ruby to just declare these dependencies in the setup method for the type.