I was reading your note and agreeing that yes, it remains possible to devise regexps that are going to cause combinatorial nasties in almost any conceivable implementation, but unconvinced about the conclusion that it is "still not advisable to run arbitrary user-provided regular expressions on your hardware", because it seems to me that the only way to find out if the regexp is evil is to run it.
But I think your closing paragraph provides a solution.
On Mon, May 15, 2023 at 8:17 AM Mike Ounsworth via Datatracker <noreply@xxxxxxxx> wrote:
…
I wonder if this
document could recommend that implementations include some sort of configurable
limit on nesting level or on recursion / backtracking depth.
That sounds like a good direction, but pretty complex. A simpler option would be that implementations impose a limit on time and/or memory costs and error out when those are breached. Do you think that a recommendation along those lines would address your concerns?
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
