[
https://issues.apache.org/jira/browse/TINKERPOP-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954122#comment-15954122
]
ASF GitHub Bot commented on TINKERPOP-891:
------------------------------------------
Github user dpitera commented on the issue:
https://github.com/apache/tinkerpop/pull/179
> Whitelisting tends to work best in cases like this as it assumes
everything is bad except for this small, easy to maintain list.
Agreed. Which is what leads me to find myself in a situation where even
things like `"^java\\.lang\\.String"` must be whitelisted to be called.
However....["^java\\.lang\\.String#getBoolean\\("](http://docs.oracle.com/javase/6/docs/api/java/lang/Boolean.html#getBoolean(java.lang.String))
must be blacklisted because it leaks implementations details about the
underlying System.
I believe this is a prime example for situations where the best filter is
something like:
`!methodBlackList.any { descriptor =~ it } && methodWhiteList.any {
descriptor =~ it }`.
Would you agree?
> I don't see a reference to methodBlackList in this PR
This is because the methodBlackList of which I speak is part of the
deprecated sadnbox extension classes
> Re-examine Sandboxing Abstractions
> ----------------------------------
>
> Key: TINKERPOP-891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-891
> Project: TinkerPop
> Issue Type: Improvement
> Components: groovy
> Affects Versions: 3.0.2-incubating
> Reporter: stephen mallette
> Assignee: stephen mallette
> Priority: Minor
> Fix For: 3.1.1-incubating
>
>
> The sandboxing abstractions are not so good a set of building blocks as I'd
> once thought. Helper methods aren't in the right places and more flexibilty
> is required in managing methods/variables than just simple filters. Need to
> develop more concrete actions on this still.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
