FELIX-6843: 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.

[sahvx655-wq]

Circling back on the framework question. When I reverted the framework source changes earlier I left the framework.tck dependency bump in by accident, so the diff still looked like it reached into framework. I've now dropped those tck.bndrun/pom.xml changes too, so the PR is confined to the two gogo Posix classes plus the jline test.

On whether other framework implementations need to be concerned: no. The change sits entirely inside gogo's grep command, wrapping the user-supplied line in a bounded CharSequence that aborts matching once a time budget is exceeded. Nothing in the framework or in how gogo gets installed is affected. PosixTest passes locally, all 9 cases including the ReDoS timeout ones.