paulk-asert commented on a change in pull request #1282:
URL: https://github.com/apache/groovy/pull/1282#discussion_r442178080
##########
File path:
src/main/java/org/codehaus/groovy/control/customizers/SecureASTCustomizer.java
##########
@@ -94,24 +94,28 @@
import java.util.Map;
/**
- * This customizer allows securing source code by controlling what code
constructs are allowed. For example, if you only
- * want to allow arithmetic operations in a groovy shell, you can configure
this customizer to restrict package imports,
- * method calls and so on.
+ * This customizer allows securing source code by controlling what code
constructs are permitted.
+ * This is typically done when using Groovy for its scripting or domain
specific language (DSL) features.
+ * For example, if you only want to allow arithmetic operations in a groovy
shell,
+ * you can configure this customizer to restrict package imports, method calls
and so on.
* <p>
- * Most of the security customization options found in this class work with
either blacklist or whitelist. This means that, for a
- * single option, you can set a whitelist OR a blacklist, but not both. You
can mix whitelist/blacklist strategies for
- * different options. For example, you can have import whitelist and tokens
blacklist.
+ * Most of the security customization options found in this class work with
either <i>allowed</i> or <i>disallowed</i> lists.
+ * This means that, for a single option, you can set an allowed list OR a
disallowed list, but not both.
+ * You can mix allowed/disallowed strategies for different options.
+ * For example, you can have an allowed import list and a disallowed tokens
list.
* <p>
- * The recommended way of securing shells is to use whitelists because it is
guaranteed that future features of the
- * Groovy language won't be allowed by defaut. Using blacklists, you can limit
the features of the languages by opting
- * out, but new language features would require you to update your
configuration.
+ * The recommended way of securing shells is to use allowed lists because it
is guaranteed that future features of the
+ * Groovy language won't be accidentally allowed unless explicitly added to
the allowed list.
+ * Using disallowed lists, you can limit the features of the language
constructs supported by your shell by opting
+ * out, but new language features are then implicitly also available and this
may not be desirable.
+ * The implication is that you might need to update your configuration with
each new release.
* <p>
- * If you set neither a whitelist nor a blacklist, then everything is
authorized.
+ * If you set neither an allowed list nor a disallowed list, then everything
is permitted.
Review comment:
both suggestions sound good to me
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
