Kyle Meyer <[email protected]> wrote:
> Eric Wong writes:
>
> > Have you run any performance tests?
>
> No. To get an idea of how to approach that, would you suggest I look at
> xt/perf-msgview.t?
Yeah, probably that with some tweaks; or running -httpd with ab,
wrk or some other HTTP benchmark that uses persistent connections.
I'm OK with things being slower with this option enabled, but
not with trivial denial-of-service vectors.
> > I'm actually more worried about the '0' (of '{0,}') or '*' being
> > combined with '?'. I can't remember if there's a pathological
> > case in that...
>
> Ah, okay, sorry for missing that.
No worries. I've dealt with some nasty pathological slowdowns
in perl(-inspired) regex engines over the years and forget most
people haven't. I recall perl itself seemed less susceptible to
pathological cases than engines inspired by it, but also wasn't
immune to them.
Maybe there's a compilation of known DoS-able regexp examples
which affect Perl somewhere.
> > The upper bound of N is a smaller concern, especially for
> > non-spam messages which only have non-space tokens of reasonable
> > length.
> >
> > Maybe changing the three existing '+' to {1,M} would be a way to
> > ameliorate the problem (though I'm not sure what a good value of
> > M would be, 255?).
>
> Me neither, though I suspect 255 would be sufficient.
Alright. There may be some other limits common to what SMTP
servers accept for line limits and such. RFC 5322 limits
raw lines to 998, but that doesn't account for lengths after
decoding.
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
