Copilot commented on code in PR #414:
URL: https://github.com/apache/commons-jexl/pull/414#discussion_r3889593722
##########
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java:
##########
@@ -2409,4 +2409,75 @@ void setOptions(final JexlOptions options) {
assertEquals("zero", jexl.createExpression("array.0").evaluate(jc));
assertEquals("one", jexl.createExpression("array.1").evaluate(jc));
}
+
+ // ----- security fixes f012 / f013 / f014 -----
+
+ /**
+ * f014: BigInteger literal with more digits than MAX_BIGINTEGER_DIGITS
must be rejected at parse time.
+ */
+ @Test
+ void testBigIntegerLiteralTooLong() {
+ // normal H-literal still works
+ assertNotNull(JEXL.createScript("42H"));
+ // a literal just over the cap (4096 + 1 digits + 'H') must fail to
parse
Review Comment:
This comment hardcodes a 4096-digit limit, but the actual parse-time cap is
not asserted here and currently differs from this value (see
NumberParser.MAX_BIGINTEGER_DIGITS). Consider rewording to avoid baking in a
potentially incorrect constant.
##########
src/main/java/org/apache/commons/jexl3/JexlArithmetic.java:
##########
@@ -591,10 +598,14 @@ public Boolean contains(final Object container, final
Object value) {
}
// use arithmetic / pattern matching ?
if (container instanceof java.util.regex.Pattern) {
- return ((java.util.regex.Pattern)
container).matcher(value.toString()).matches();
+ return ((java.util.regex.Pattern) container).matcher(new
InterruptibleCharSequence(value.toString())).matches();
}
Review Comment:
REGEX_PATTERN_MAX_LENGTH is only enforced when the right-hand side is a
CharSequence. When the regex is precompiled (or cached as a Pattern via
Interpreter.resolvePattern), this branch bypasses the length guard, so overly
long patterns can still be accepted and evaluated.
##########
src/main/java/org/apache/commons/jexl3/JexlArithmetic.java:
##########
@@ -1746,7 +1783,7 @@ private BigDecimal parseBigDecimal(final String arg)
throws ArithmeticException
*/
private BigInteger parseBigInteger(final String arg) throws
ArithmeticException {
try {
- return arg.isEmpty()? BigInteger.ZERO : new BigInteger(arg);
+ return arg.isEmpty() ? BigInteger.ZERO :
checkBigIntegerPrecision(new BigInteger(arg));
} catch (final NumberFormatException e) {
throw new CoercionException("BigDecimal coercion: ("+ arg +")", e);
Review Comment:
parseBigInteger() wraps a NumberFormatException as a CoercionException
labeled "BigDecimal coercion", which is misleading for BigInteger parsing
errors.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
