Fix ReDoS vulnerability in grep command

[sahvx655-wq]

This PR fixes a ReDoS vulnerability in the grep command for both gogo/shell and gogo/jline.

The fix adds timeout protection for user-supplied regular expressions to prevent catastrophic backtracking patterns such as (a+)+ from causing excessive CPU usage or hanging the process.

A regression test (testGrepReDosTimeout) was also added to verify the fix.

[pigelvy]

Similar to my PR#501 build failures (#501 (comment)), here also the Maven dependency assertj-core cannot be found...

[tjwatson]

I am curious why a fix to the gogo grep command requires changes to the Felix framework? And do other framework implementations need to be concerned with the changes required here to fix the gogo grep command when gogo is installed?

[sahvx655-wq]

I am curious why a fix to the gogo grep command requires changes to the Felix framework? And do other framework implementations need to be concerned with the changes required here to fix the gogo grep command when gogo is installed?

Thanks for reviewing.
You’re right to question the Felix framework changes — those were accidentally included from another branch. I have reverted them, and this PR now only contains the gogo grep ReDoS timeout fix.Regarding the CI failure, it appears to be due to dependency resolution issues (assertj-core / TCK setup). I aligned the TCK dependencies by upgrading byte-buddy to 1.18.0 and re-resolved the tck.bndrun to ensure consistent resolution.

[chrisrueger]

"in theory" this System.currentTimeMillis() + timeoutMs; could overun and lead to timeoutTime become negative which would cause checkTimeout() to always throw.

e.g. if somebody passes timeoutMs = Long.MAX_VALUE to mean "no timeout"

[sahvx655-wq]

Thanks for catching this. I've switched to System.nanoTime(), added overflow protection for timeout conversion, and propagated the timing state to subsequences to avoid drift.