From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 43CE61F4B4; Sat, 10 Apr 2021 05:15:50 +0000 (UTC) Date: Sat, 10 Apr 2021 05:15:50 +0000 From: Eric Wong To: Kyle Meyer Cc: meta@public-inbox.org Subject: Re: archive links broken with obfuscate=true Message-ID: <20210410051550.GA4654@dcvr> References: <87a6q8p5qa.fsf@kyleam.com> <20210409102129.GA16787@dcvr> <87zgy7rs9q.fsf@kyleam.com> <20210409233700.GA11190@dcvr> <87sg3ysrzu.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87sg3ysrzu.fsf@kyleam.com> List-Id: Kyle Meyer 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.