[GitHub] [commons-text] codecov-commenter commented on pull request #375: Use java8 Stream.
codecov-commenter commented on PR #375: URL: https://github.com/apache/commons-text/pull/375#issuecomment-1297727621 # [Codecov](https://codecov.io/gh/apache/commons-text/pull/375?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#375](https://codecov.io/gh/apache/commons-text/pull/375?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (8d054e7) into [master](https://codecov.io/gh/apache/commons-text/commit/9692573a0de77c0427dc20d5f2e4bbd38b870c39?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (9692573) will **increase** coverage by `0.03%`. > The diff coverage is `96.15%`. ```diff @@ Coverage Diff @@ ## master #375 +/- ## + Coverage 97.12% 97.15% +0.03% + Complexity 2324 2315 -9 Files84 84 Lines 5770 5695 -75 Branches935 895 -40 - Hits 5604 5533 -71 + Misses 87 83 -4 Partials 79 79 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-text/pull/375?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...c/main/java/org/apache/commons/text/WordUtils.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9Xb3JkVXRpbHMuamF2YQ==) | `93.56% <0.00%> (+1.81%)` | :arrow_up: | | [...ava/org/apache/commons/text/AlphabetConverter.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9BbHBoYWJldENvbnZlcnRlci5qYXZh) | `96.59% <100.00%> (-0.03%)` | :arrow_down: | | [...org/apache/commons/text/RandomStringGenerator.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9SYW5kb21TdHJpbmdHZW5lcmF0b3IuamF2YQ==) | `92.95% <100.00%> (-0.47%)` | :arrow_down: | | [.../main/java/org/apache/commons/text/StrBuilder.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9TdHJCdWlsZGVyLmphdmE=) | `97.34% <100.00%> (-0.05%)` | :arrow_down: | | [...ain/java/org/apache/commons/text/StrTokenizer.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9TdHJUb2tlbml6ZXIuamF2YQ==) | `98.77% <100.00%> (-0.02%)` | :arrow_down: | | [.../java/org/apache/commons/text/StringTokenizer.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9TdHJpbmdUb2tlbml6ZXIuamF2YQ==) | `98.64% <100.00%> (-0.02%)` | :arrow_down: | | [...ava/org/apache/commons/text/TextStringBuilder.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9UZXh0U3RyaW5nQnVpbGRlci5qYXZh) | `97.68% <100.00%> (-0.05%)` | :arrow_down: | | [...he/commons/text/matcher/AbstractStringMatcher.java](https://codecov.io/gh/apache/commons-text/pull/375/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdGV4dC9tYXRjaGVyL0Fic3RyYWN0U3RyaW5nTWF0Y2hlci5qYXZh) | `100.00% <100.00%> (ø)` | | | [...ache/commons/text/similarity/CosineSimilarity.java](https://codecov.io/gh/apache/commons-text/pull/
[GitHub] [commons-text] garydgregory commented on pull request #375: Use java8 Stream.
garydgregory commented on PR #375: URL: https://github.com/apache/commons-text/pull/375#issuecomment-1297664799 The code does not compile @arturobernalg -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626766#comment-17626766 ] Dmitri Blinov edited comment on JEXL-381 at 10/31/22 7:07 PM: -- [~henrib] I don't remember exact reason why I didn't opt for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) was (Author: dmitri_blinov): [~henrib] I don't remember exact reason why I didn't opted for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626766#comment-17626766 ] Dmitri Blinov commented on JEXL-381: [~henrib] I don't remember exact reason why I didn't opted for the new way of defining restrictions. May be its because I wanted to exclude NoJexl annotation checks to save some cycles and there was no way to override the default behavior for a private method ) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626740#comment-17626740 ] Henri Biestro edited comment on JEXL-381 at 10/31/22 6:13 PM: -- [~dmitri_blinov], I would hope that JexlPermissions (JEXL-357) now solve this issue more easily. In particular, the list of constructor to disable should be easier to describe (see JexlPermissions.parse(...)). was (Author: henrib): [~dmitri_blinov], I would hope that JexlPermissions (JEXL-357) now solve this issue more easily. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626730#comment-17626730 ] Henri Biestro edited comment on JEXL-381 at 10/31/22 6:11 PM: -- [~ggregory], 'Permeability' was intended as 'how much' of the host platform (application, server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed implemented by permissions so my bad for misnaming the intent, permissibility is certainly a better word. I don't understand your proposal in functional terms: how would the usability level enum be used for and what would it bring? Would it be more than an homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom' configurations in our components? Couldn't it be done through a convention, having a per-component enum at the top-level with the same name for each component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?) When and how to use these/this enum would be very specific anyway per project. They would always be a required argument in some configuration method to describe the permissivity of any Commons instance / singleton component but not the sole one. In JEXL's case, the basic method would be implemented through factory/static-getters to instantiate/retrieve permissions. But this still makes JEXL-381 a valid case as is; I would create another JIRA to use this new tbd component when it is released. was (Author: henrib): 'Permeability' was intended as 'how much' of the host platform (application, server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed implemented by permissions so my bad for misnaming the intent, permissibility is certainly a better word. I don't understand your proposal in functional terms: how would the usability level enum be used for and what would it bring? Would it be more than an homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom' configurations in our components? Couldn't it be done through a convention, having a per-component enum at the top-level with the same name for each component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?) When and how to use these/this enum would be very specific anyway per project. They would always be a required argument in some configuration method to describe the permissivity of any Commons instance / singleton component but not the sole one. In JEXL's case, the basic method would be implemented through factory/static-getters to instantiate/retrieve permissions. But this still makes JEXL-381 a valid case as is; I would create another JIRA to use this new tbd component when it is released. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626740#comment-17626740 ] Henri Biestro edited comment on JEXL-381 at 10/31/22 6:11 PM: -- [~dmitri_blinov], I would hope that JexlPermissions (JEXL-357) now solve this issue more easily. was (Author: henrib): Dmitri, I would hope that JexlPermissions (JEXL-357) now solve this issue more easily. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626740#comment-17626740 ] Henri Biestro commented on JEXL-381: Dmitri, I would hope that JexlPermissions (JEXL-357) now solve this issue more easily. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626730#comment-17626730 ] Henri Biestro edited comment on JEXL-381 at 10/31/22 6:06 PM: -- 'Permeability' was intended as 'how much' of the host platform (application, server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed implemented by permissions so my bad for misnaming the intent, permissibility is certainly a better word. I don't understand your proposal in functional terms: how would the usability level enum be used for and what would it bring? Would it be more than an homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom' configurations in our components? Couldn't it be done through a convention, having a per-component enum at the top-level with the same name for each component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?) When and how to use these/this enum would be very specific anyway per project. They would always be a required argument in some configuration method to describe the permissivity of any Commons instance / singleton component but not the sole one. In JEXL's case, the basic method would be implemented through factory/static-getters to instantiate/retrieve permissions. But this still makes JEXL-381 a valid case as is; I would create another JIRA to use this new tbd component when it is released. was (Author: henrib): 'Permeability' was intended as 'how much' of the host platform (application, server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed implemented by permissions so my bad for misnaming the intent, permissibility is certainly a better word. I don't understand your proposal in functional terms: how would the usability level enum be used for and what would it bring? Would it be more than an homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom' configurations in our components? Couldn't it be done through a convention, having a per-component enum at the top-level with the same name for each component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?) When and how to use these/this enum would be very specific anyway per project. They would be the go-to point to describe the permissively of an instance / singleton component. In JEXL's case, this would be implemented through factory/static-getters to instantiate/retrieve permissions. Still makes JEXL-381 a valid case as is; could create another JIRA to use this new component enum when it is released. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[
https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626731#comment-17626731
]
Dmitri Blinov commented on JEXL-381:
IMO the idea to sandbox JEXL by default is not without good sense, since there
might be people around who are not experienced in security problems. Jexl may
provide them with some basics.
My experience in sandboxing JEXL, so that it would be difficult to use it as a
security hole, is that you need to hinder many access paths, not only disabling
access to certain packages, but preventing access to object classloader for
example, since there is possibility to obtain the restricted object by calling
ClassLoader.findClass() or Class.forName("") and bypass standard constructor
package checks. Other obvious measures are restricting access to
java.lang.System static methods, like System.exit(code). My currentl list for
completely restricted class methods is
"java.lang.System", "java.lang.Compiler", "java.lang.Process",
"java.lang.ProcessBuilder", "java.lang.Runtime",
"java.lang.RuntimePermission", "java.lang.SecurityManager", "java.lang.Thread",
"java.lang.ThreadGroup",
"java.lang.ClassLoader", "java.net.URLClassLoader", "java.io.FileDescriptor"
Here is my list to restricted constructors - IMO its ok to work with objects if
you get them somehow, via secured api, but you should not be able to create
those objects in uncontrolled manner
"java.io.File", "java.io.FileDescriptor", "java.io.FileInputStream",
"java.io.FileOutputStream",
"java.io.FilePermission", "java.io.FileReader", "java.io.FileWriter",
"java.io.PrintStream", "java.io.PrintWriter",
"java.io.RandomAccessFile", "java.io.ObjectInputStream",
"java.util.zip.ZipFile", "java.util.jar.JarFile",
"java.net.URL", "java.net.URLClassLoader"
Other resticted methods are
{code:java}
// Prevent direct invocation
if (Class.class.isAssignableFrom(clazz) && ("forName".equals(method) ||
"getClassLoader".equals(method)))
return false;
// Prevent direct invocation
if (Method.class.isAssignableFrom(clazz) && ("invoke".equals(method) ||
"setAccessible".equals(method)))
return false;
// Prevent direct invocation
if (MethodHandle.class.isAssignableFrom(clazz) &&
("invoke".equals(method) || "invokeExact".equals(method)))
return false;
// Prevent direct invocation
if (Constructor.class.isAssignableFrom(clazz) &&
"newInstance".equals(method))
return false;
// Prevent direct invocation
if (File.class.isAssignableFrom(clazz) &&
("createTempFile".equals(method) || "listRoots".equals(method)))
return false;
// Prevent direct invocation
if (URL.class.isAssignableFrom(clazz) &&
"setURLStreamHandlerFactory".equals(method))
return false;
{code}
So, there is alot to think about...
> Change default JEXL configuration to a more security-friendly behaviour
>
>
> Key: JEXL-381
> URL: https://issues.apache.org/jira/browse/JEXL-381
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> WHAT:
> JEXL's default builder allows accessing and calling any public method, field
> or constructor of any public class. This might not be desirable since a quick
> exploration of JEXL will quickly conclude the library allows arbitrary
> execution through commands (ProcessBuilder) or getting to the file-system
> through URL or File. This improvement goal is to change JEXL's permeability
> as an explicit option and user decision, not a default behaviour.
> HOW:
> By changing the current JexlBuilder to use a restricted set of permissions
> whilst instantiating the Uberspect, we can ensure a minimal useful set of
> classes can be accessed and only those by default. By removing access to
> almost all classes that interact with the JVM host and file-system, we ensure
> a default isolation that would significantly reduce the ability to use JEXL
> as an attack vector.
> CAVEAT:
> This change will likely break many scripts that were dependant upon the
> default permeability.
> [~ggregory], [~dmitri_blinov] your opinions are welcome :-)
> https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626730#comment-17626730 ] Henri Biestro commented on JEXL-381: 'Permeability' was intended as 'how much' of the host platform (application, server/service, JVM, OS, file-system) is accessible by JEXL; this is indeed implemented by permissions so my bad for misnaming the intent, permissibility is certainly a better word. I don't understand your proposal in functional terms: how would the usability level enum be used for and what would it bring? Would it be more than an homogeneous way of describing the 'default/secure', 'all/unsecure', 'custom' configurations in our components? Couldn't it be done through a convention, having a per-component enum at the top-level with the same name for each component ? ( o.a.c.jexl.Permissibility vs o.a.c.text.Permissibility ?) When and how to use these/this enum would be very specific anyway per project. They would be the go-to point to describe the permissively of an instance / singleton component. In JEXL's case, this would be implemented through factory/static-getters to instantiate/retrieve permissions. Still makes JEXL-381 a valid case as is; could create another JIRA to use this new component enum when it is released. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626685#comment-17626685
]
Alex Herbert commented on NUMBERS-29:
-
{quote}Are you sure about the API (a new StirlingS2 class)?
{quote}
I have no string opinion on the name. Any suggestions are welcome.
My suggestion was based on the other classes in the combinatorics package that
have a class for each computation. However the FactorialDouble is now
deprecated and methods have been moved to Factorial. So multiple methods can be
in the same class which would fit with the Stirling numbers.
To allow for future methods then perhaps one of:
{code:java}
long StirlingNumbers.stirlingS2(int n, int k)
long StirlingNumbers.s2(int n, int k)
long Stirling.stirlingS2(int n, int k)
long Stirling.s2(int n, int k){code}
The StirlingNumbers.stirlingS2 may be the best fit with the current verbose
naming in the Numbers hierarchy.
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
> Components: combinatorics
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.2
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626676#comment-17626676
]
Gilles Sadowski commented on NUMBERS-29:
bq. I suggest adding to the combinatorics package [...]
Are you sure about the API (a new {{StirlingS2}} class)?
Or postpone until we [figure out|https://en.wikipedia.org/wiki/Stirling_number]
about a {{Stirling}} class?
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
> Components: combinatorics
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.1
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-text] arturobernalg commented on a diff in pull request #375: Use java8 Stream.
arturobernalg commented on code in PR #375:
URL: https://github.com/apache/commons-text/pull/375#discussion_r1009584981
##
src/main/java/org/apache/commons/text/similarity/IntersectionSimilarity.java:
##
@@ -125,12 +125,7 @@ int uniqueElementSize() {
* @return The intersection
*/
private static int getIntersection(final Set setA, final Set
setB) {
-int intersection = 0;
-for (final T element : setA) {
-if (setB.contains(element)) {
-intersection++;
-}
-}
+int intersection = (int) setA.stream().filter(setB::contains).count();
Review Comment:
inline.
meanwhile I have change your remarks.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-29:
Component/s: combinatorics
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
> Components: combinatorics
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.1
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NUMBERS-30) Move "array" utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-30:
Component/s: arrays
> Move "array" utilities from "Commons Math"
> --
>
> Key: NUMBERS-30
> URL: https://issues.apache.org/jira/browse/NUMBERS-30
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.1
>
>
> Create a new {{commons-numbers-sequence}} module to contain (most of) the
> code currently in the following classes (in package {{o.a.c.math4.util}}):
> * {{MathArrays}}
> * {{IntegerSequence}}
> * {{ResizableDoubleArray}}
> * {{MultidimensionalCounter}}
> * ...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626651#comment-17626651
]
Alex Herbert commented on NUMBERS-29:
-
I have spent some time looking at stirlingS2. I fixed one bug for S(n, k) when
k==2 and s>64. Fix and test pushed to master.
The main implementation to compute the S2 number has no test coverage of a
successful computation (i.e. all test input is expected to throw an exception).
The final part of that computation divides the sum by k!. This will be limited
to maximum k of 20. However there are some cases that should compute a result:
{noformat}
S(26, 3) = 423610750290L
S(26, 4) = 187226356946265L
S(26, 23) = 4126200
S(26, 24) = 47450{noformat}
These currently raise an overflow as the implementation sums terms of
alternating magnitude and checks for a negative sum at each step. It should
only check for a negative sum when an addition to the sum has been made.
I locally fixed the implementation as:
{code:java}
// definition formula: note that this may trigger some overflow
// S(n, k) = [ sum_{i=0}^k (-1)^i binom(k, i) (k - i)^n ] / k!
long sum = 0;
long sign = ((k & 0x1) == 0) ? 1 : -1;
// Compute terms in ascending magnitude: j == k - i
// Check the sum for overflow only after additions.
for (int j = 1; j <= k; ++j) {
sign = -sign;
// FIXED here to check sign on additions only
sum += sign * Math.multiplyExact(BinomialCoefficient.value(k, j),
ArithmeticUtils.pow((long) j, n));
if (sign == 1 && sum < 0) {
// there was an overflow somewhere
throw new
MathArithmeticException(LocalizedFormats.ARGUMENT_OUTSIDE_DOMAIN,
n, 0, stirlingS2.length - 1);
}
}
return sum / Factorial.value(k); {code}
I did not push this fix to math git master as the exceptions are sometimes a
java.lang.ArithmeticException and sometimes MathArithmeticException (does not
extend ArithmeticException). These should be consolidated to all be the same
type.
Note also that this computation divides by k!. So will throw an exception for
any k > 20. This could be checked before doing the loop. It is also possible to
compute the largest used binomial coefficient first. If this is OK then the
rest can be computed by downward recursion: binom(n , k-1) = binom(n, k) * k /
(n-k+1). Thus only one call to binomial coefficient is required. These can be
computed and stored in an array to exploit reuse via symmetry: binom(n, k) =
binom(n, n-k).
This method is limited to k<=20 due to the use of the factorial.
However there is an alternative implementation using forward recursion:
{code:java}
// S(n, k) = k * S(n - 1, k) + S(n - 1, k - 1)
return Math.addExact(
Math.multiplyExact(k, stirlingS2(n - 1, k)),
stirlingS2(n - 1, k - 1)
); {code}
This is not limited by k!.
A quick test using the following loop shows that when n is large then the
maximum supported value for k is close to n.
{code:java}
@Test
void test() {
int count = 0;
for (int k = 2;; k++) {
for (int n = k + 3;; n++) {
try {
CombinatoricsUtils.stirlingS2(n, k);
count++;
} catch (Exception ex) {
if (n == k + 3) {
// limit
return;
}
System.out.printf("S(%d, %d) %d%n", n - 1, k, count);
break;
}
}
}
} {code}
Output:
{noformat}
S(64, 2) 60
S(41, 3) 96
S(33, 4) 123
S(30, 5) 146
S(28, 6) 166
S(26, 7) 183
...
S(183, 179) 940
S(184, 180) 942
S(185, 181) 944
S(186, 182) 946
S(187, 183) 948
S(188, 184) 950
S(189, 185) 952{noformat}
When n >= 189, (n-k) <= 4. So it is possible to create some checks based on
input n and k to quickly error.
This method uses recursive method calls and is limited for very large n by a
stack overflow. I did not find this to occur in testing for k=n-3, but it did
for k=n-2. Each stirlingS2() will use 2 method calls and thus the method
recursion grows non-linearly as n increases. The recursion is terminated when
k=2 or k=n-1 and so the stack depth is limited from squared growth. At large n,
k is limited (by the value of the final result) to be close to n so the
computation recursion using S(n-1, k) will at most recurse a few method calls.
The main recursion will be in the S(n-1, k-1) call which could recurse
thousands of calls.
Note that the other implementation cannot compute these values at all.
A check with mathematica shows that large n can be computed and the cut-off is
below n=2800, k=n-3, e.g.
{noformat}
StirlingS2[2000, 1997] = 1326015650507998500
StirlingS2[2500, 2497] = 5063921680676560625
StirlingS2[2750, 2747] = 8974638660543443250
// Too large
StirlingS2[2800, 2797] = 1001047387677900
StirlingS2[3000, 2997] = 15131891757955497750
{noformat}
Computation using the method recursion implemen
[GitHub] [commons-text] garydgregory commented on a diff in pull request #375: Use java8 Stream.
garydgregory commented on code in PR #375:
URL: https://github.com/apache/commons-text/pull/375#discussion_r1009555138
##
src/main/java/org/apache/commons/text/similarity/IntersectionSimilarity.java:
##
@@ -125,12 +125,7 @@ int uniqueElementSize() {
* @return The intersection
*/
private static int getIntersection(final Set setA, final Set
setB) {
-int intersection = 0;
-for (final T element : setA) {
-if (setB.contains(element)) {
-intersection++;
-}
-}
+int intersection = (int) setA.stream().filter(setB::contains).count();
Review Comment:
Whichever way we go, we probably need to Javadoc the truncation (PR) or
looping of ints (current master).
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-text] garydgregory commented on a diff in pull request #375: Use java8 Stream.
garydgregory commented on code in PR #375:
URL: https://github.com/apache/commons-text/pull/375#discussion_r1009552877
##
src/main/java/org/apache/commons/text/similarity/IntersectionSimilarity.java:
##
@@ -125,12 +125,7 @@ int uniqueElementSize() {
* @return The intersection
*/
private static int getIntersection(final Set setA, final Set
setB) {
-int intersection = 0;
-for (final T element : setA) {
-if (setB.contains(element)) {
-intersection++;
-}
-}
+int intersection = (int) setA.stream().filter(setB::contains).count();
Review Comment:
Do we still need the local variable?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-text] garydgregory commented on a diff in pull request #375: Use java8 Stream.
garydgregory commented on code in PR #375:
URL: https://github.com/apache/commons-text/pull/375#discussion_r1009545056
##
src/main/java/org/apache/commons/text/AlphabetConverter.java:
##
@@ -104,11 +104,7 @@ private static Integer[] convertCharsToIntegers(final
Character[] chars) {
if (ArrayUtils.isEmpty(chars)) {
return ArrayUtils.EMPTY_INTEGER_OBJECT_ARRAY;
}
-final Integer[] integers = new Integer[chars.length];
-for (int i = 0; i < chars.length; i++) {
-integers[i] = (int) chars[i];
-}
-return integers;
+return Arrays.stream(chars).map(aChar -> (int)
aChar).toArray(Integer[]::new);
Review Comment:
You don't need streams @arturobernalg
Why not just:
```
final Integer[] integers = new Integer[chars.length];
Arrays.setAll(integers, i -> (int) chars[i]);
```
?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-text] garydgregory commented on a diff in pull request #375: Use java8 Stream.
garydgregory commented on code in PR #375:
URL: https://github.com/apache/commons-text/pull/375#discussion_r1009545056
##
src/main/java/org/apache/commons/text/AlphabetConverter.java:
##
@@ -104,11 +104,7 @@ private static Integer[] convertCharsToIntegers(final
Character[] chars) {
if (ArrayUtils.isEmpty(chars)) {
return ArrayUtils.EMPTY_INTEGER_OBJECT_ARRAY;
}
-final Integer[] integers = new Integer[chars.length];
-for (int i = 0; i < chars.length; i++) {
-integers[i] = (int) chars[i];
-}
-return integers;
+return Arrays.stream(chars).map(aChar -> (int)
aChar).toArray(Integer[]::new);
Review Comment:
You don't need streams @arturobernalg
Why not just
```
final Integer[] integers = new Integer[chars.length];
Arrays.setAll(integers, i -> (int) chars[i]);
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626628#comment-17626628 ] Gary D. Gregory edited comment on JEXL-381 at 10/31/22 2:53 PM: I'm not sure "permeability" is the best word to use here. I think you might have meant "permissibility". Just like for Commons Text and Commons Configuration, either by FUD or hindsight, it feels like we need to do something, so propose we take a step back and consider something more useful even if it broadens the scope of this conversation. I would consider something like the list below which could be built in a new component or added to Commons Configuration in a new Maven module (which would make Configuration a multi-module Commons component) A Commons component could be defined perhaps through an enum with a useability level of: * MINIMUM aliased to DEFAULT: A "secure" but minimally functional configuration. This is the default configuration. This configuration cannot be edited programmatically. Could this be a problem when the library is used in more than one place? Needs further thought, probably not since we also have USER. * CUSTOM: A programmatically defined configuration. This configuration cannot be edited after construction. * USER: Defined from system properties, environment variables, and config files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or CUSTOM configuration to be edited through the means listed previously. * ALL: The kitchen sink, caveat emptor. Thoughts? was (Author: garydgregory): I'm not sure "permeability" is the best word to use here. I think you might have meant "permissibility". Just like for Commons Text and Commons Configuration, either by FUD or hindsight, it feels like we need to do something, so propose we take a step back and consider something more useful even if it broadens the scope of this conversation. I would consider something like the list below which could be built in a new component or added to Commons Configuration in a new Maven module (which would make Configuration a multi-module Commons component) A Commons component could be defined perhaps through an enum with a useability level of: * MINIMUM aliased to DEFAULT: A "secure" but minimally functional configuration. This is the default configuration. This configuration cannot be edited programmatically. Could this be a problem when the library is used in more than one place? Needs further thought, probably not since we also have USER. * CUSTOM: A programmatically defined configuration. This configuration cannot be edited after construction. * USER: Defined from system properties, environment variables, and config files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or CUSTOM configuration to be edited. * ALL: The kitchen sink, caveat emptor. Thoughts? > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626628#comment-17626628 ] Gary D. Gregory edited comment on JEXL-381 at 10/31/22 2:51 PM: I'm not sure "permeability" is the best word to use here. I think you might have meant "permissibility". Just like for Commons Text and Commons Configuration, either by FUD or hindsight, it feels like we need to do something, so propose we take a step back and consider something more useful even if it broadens the scope of this conversation. I would consider something like the list below which could be built in a new component or added to Commons Configuration in a new Maven module (which would make Configuration a multi-module Commons component) A Commons component could be defined perhaps through an enum with a useability level of: * MINIMUM aliased to DEFAULT: A "secure" but minimally functional configuration. This is the default configuration. This configuration cannot be edited programmatically. Could this be a problem when the library is used in more than one place? Needs further thought, probably not since we also have USER. * CUSTOM: A programmatically defined configuration. This configuration cannot be edited after construction. * USER: Defined from system properties, environment variables, and config files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or CUSTOM configuration to be edited. * ALL: The kitchen sink, caveat emptor. Thoughts? was (Author: garydgregory): I'm not sure "permeability" is the best word to use here. I think you might have meant "permissibility". Just like for Commons Text and Commons Configuration, either by FUD or hindsight, it feels like we need to do something, so propose we take a step back and consider something more useful even if it broadens the scope of this conversation. I would consider something the list below which could be built in a new component or added to Commons Configuration in a new Maven module (which would make Configuration a multi-module Commons component) A Commons component could be defined perhaps through an enum with a useability level of: * MINIMUM aliased to DEFAULT: A "secure" but minimally functional configuration. This is the default configuration. This configuration cannot be edited programmatically. Could this be a problem when the library is used in more than one place? Needs further thought, probably not since we also have USER. * CUSTOM: A programmatically defined configuration. This configuration cannot be edited after construction. * USER: Defined from system properties, environment variables, and config files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or CUSTOM configuration to be edited. * ALL: The kitchen sink, caveat emptor. Thoughts? > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626628#comment-17626628 ] Gary D. Gregory commented on JEXL-381: -- I'm not sure "permeability" is the best word to use here. I think you might have meant "permissibility". Just like for Commons Text and Commons Configuration, either by FUD or hindsight, it feels like we need to do something, so propose we take a step back and consider something more useful even if it broadens the scope of this conversation. I would consider something the list below which could be built in a new component or added to Commons Configuration in a new Maven module (which would make Configuration a multi-module Commons component) A Commons component could be defined perhaps through an enum with a useability level of: * MINIMUM aliased to DEFAULT: A "secure" but minimally functional configuration. This is the default configuration. This configuration cannot be edited programmatically. Could this be a problem when the library is used in more than one place? Needs further thought, probably not since we also have USER. * CUSTOM: A programmatically defined configuration. This configuration cannot be edited after construction. * USER: Defined from system properties, environment variables, and config files (see Commons Configuration). An app that sets this _allows_ a DEFAULT or CUSTOM configuration to be edited. * ALL: The kitchen sink, caveat emptor. Thoughts? > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-381: --- Description: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. [~ggregory], [~dmitri_blinov] your opinions are welcome :-) https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd was: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. [~dmitri_blinov] your opinion welcome :-) https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-381: --- Description: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. [~dmitri_blinov] you opinion welcome :-) https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd was: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~dmitri_blinov] you opinion welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-381: --- Description: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. [~dmitri_blinov] your opinion welcome :-) https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd was: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. [~dmitri_blinov] you opinion welcome :-) https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~dmitri_blinov] your opinion welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-381: --- Description: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd was: WHAT: JEXL's default builder allows accessing and calling any public method, field or constructor of any public class. This might not be desirable since a quick exploration of JEXL will quickly conclude the library allows arbitrary execution through commands (ProcessBuilder) or getting to the file-system through URL or File. This improvement goal is to change JEXL's permeability as an explicit option and user decision, not a default behaviour. HOW: By changing the current JexlBuilder to use a restricted set of permissions whilst instantiating the Uberspect, we can ensure a minimal useful set of classes can be accessed and only those by default. By removing access to almost all classes that interact with the JVM host and file-system, we ensure a default isolation that would significantly reduce the ability to use JEXL as an attack vector. CAVEAT: This change will likely break many scripts that were dependant upon the default permeability. > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-configuration] garydgregory commented on pull request #221: Bump commons-text from 1.9 to 1.10.0
garydgregory commented on PR #221: URL: https://github.com/apache/commons-configuration/pull/221#issuecomment-1296938828 @mohammadmaulana Apache Commons Text 1.10.0 is already released, you can use it from you applications. There is no schedule as of yet for the next release of Commons Configuration. We do not create a release just to update a dependency since an app can do that on it's own. Note that we are volunteering our time. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-382. Resolution: Fixed Nice one Dmitri! Commit [81e2be9|https://github.com/apache/commons-jexl/commit/81e2be9bbf2fa4e1be81a329f23cd357d0818b89]. > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-382: --- Fix Version/s: 3.3 > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Priority: Major > Fix For: 3.3 > > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-382: --- Assignee: Henri Biestro > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JEXL-382) Simplify grammar and lexical state management
[ https://issues.apache.org/jira/browse/JEXL-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-382: --- Affects Version/s: 3.2.1 > Simplify grammar and lexical state management > - > > Key: JEXL-382 > URL: https://issues.apache.org/jira/browse/JEXL-382 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Dmitri Blinov >Priority: Major > > Here is the proposal to tidy up grammar and lexical state management rules. > The jar size reduction is also a small bonus to code cleanup > https://github.com/apache/commons-jexl/pull/134 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-jexl] henrib merged pull request #133: Bump actions/upload-artifact from 3.1.0 to 3.1.1
henrib merged PR #133: URL: https://github.com/apache/commons-jexl/pull/133 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] henrib merged pull request #128: Bump spotbugs-maven-plugin from 4.7.2.0 to 4.7.2.1
henrib merged PR #128: URL: https://github.com/apache/commons-jexl/pull/128 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] henrib merged pull request #125: Bump asm from 9.3 to 9.4
henrib merged PR #125: URL: https://github.com/apache/commons-jexl/pull/125 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] henrib merged pull request #134: Simplify grammar and lexical state management
henrib merged PR #134: URL: https://github.com/apache/commons-jexl/pull/134 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] henrib commented on pull request #134: Simplify grammar and lexical state management
henrib commented on PR #134: URL: https://github.com/apache/commons-jexl/pull/134#issuecomment-1296857430 Nice ! I've a tiny modification wrt keywords list and 'dot id' handling. I'm fighting with git though... Created a branch, trying to merge back in your PR, will find a way momentarily. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-configuration] mohammadmaulana commented on pull request #221: Bump commons-text from 1.9 to 1.10.0
mohammadmaulana commented on PR #221: URL: https://github.com/apache/commons-configuration/pull/221#issuecomment-1296830575 hi @garydgregory, please help to confirm, when the next version will be released? since this is fix for this critical vulnerability issue https://nvd.nist.gov/vuln/detail/CVE-2022-42889 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
