paulk-asert opened a new pull request, #2812:
URL: https://github.com/apache/groovy/pull/2812
…p regexes
Two defects in the same {@snippet} handling, both reached from a doc comment
in the source being documented.
The class and id attributes were appended to the generated element without
encoding. The attribute parser accepts a double quote inside a value which was
single quoted or unquoted, so a value could close its attribute and the tag
around it. Encode both through a new SimpleGroovyClassDoc.encodeAttribute,
which escapes the ampersand first and then the characters that can end an
attribute or start a tag. The snippet body was already escaped; this brings the
attributes up to the same standard.
A markup directive's regex attribute was compiled and run against snippet
lines with no bound. Give each directive a deadline using RegexGuard, and leave
the line unannotated rather than half annotated if it expires.
The payload in the test is worth a note. The finding cites (a+)+$ against a
long run of characters, and on a current JDK that is not slow: the textbook
nested-quantifier patterns, (a+)+b, (a|aa)+$, (x+x+)+y and (a*)*b among them,
all complete in about a millisecond, because the engine recognises them. A
backreference still backtracks exponentially. Measured with the guard removed,
a directive carrying (a+)+\1b against a 32 character line took 152 seconds to
render one page, and grows exponentially with the line; with the guard the same
page renders in well under a second. So the finding is right that the risk
exists and wrong about how it is reached, and a test built on its own example
would have passed with or without a fix.
--
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]
