This is from https://github.com/unicode-org/icu4x/security/advisories/GHSA-c8m9-943c-5xmw, which I mostly addressed but didn't look at this last option.
The bug report contained this:
File: components/segmenter/src/complex/dictionary.rs:57-73
Nested loop over dictionary matches and grapheme boundaries could theoretically exhibit O(n*m) behavior with adversarial text
combining complex scripts. In practice, grapheme boundaries are well-bounded, but pathological input with many combining characters
could amplify costs.
There are ways to do pathologically large graphemes in Unicode, but most of them will cause this algorithm to consume the grapheme and move on. I don't think there are problems here, but I want to check this.
@sffc @aethanyc @makotokato @hsivonen
This is from https://github.com/unicode-org/icu4x/security/advisories/GHSA-c8m9-943c-5xmw, which I mostly addressed but didn't look at this last option.
The bug report contained this:
File: components/segmenter/src/complex/dictionary.rs:57-73
Nested loop over dictionary matches and grapheme boundaries could theoretically exhibit O(n*m) behavior with adversarial text
combining complex scripts. In practice, grapheme boundaries are well-bounded, but pathological input with many combining characters
could amplify costs.
There are ways to do pathologically large graphemes in Unicode, but most of them will cause this algorithm to consume the grapheme and move on. I don't think there are problems here, but I want to check this.
@sffc @aethanyc @makotokato @hsivonen