Re: archive links broken with obfuscate=true

[Kyle Meyer <kyle@kyleam.com>]

Eric Wong writes:

> Oops, I think the following fixes it, but not sure if there's a
> better way to accomplish the same thing....

Thanks.  Jumping around a bit with that installed, I haven't spotted any
remaining issues.

> I worry the regexp change is susceptible to performance problems
> from malicious inputs.  I can't remember if something like this
> triggers a pathological case or not, or if I'm confusing this
> with another quirk that does (or quirks of another RE engine)

Hmm...

> diff --git a/lib/PublicInbox/Hval.pm b/lib/PublicInbox/Hval.pm
> index d20f70ae..6f1a046c 100644
> --- a/lib/PublicInbox/Hval.pm
> +++ b/lib/PublicInbox/Hval.pm
> @@ -82,15 +82,17 @@ sub obfuscate_addrs ($$;$) {
>  	my $repl = $_[2] // '•';
>  	my $re = $ibx->{-no_obfuscate_re}; # regex of domains
>  	my $addrs = $ibx->{-no_obfuscate}; # { $address => 1 }
> -	$_[1] =~ s/(([\w\.\+=\-]+)\@([\w\-]+\.[\w\.\-]+))/
> -		my ($addr, $user, $domain) = ($1, $2, $3);
> -		if ($addrs->{$addr} || ((defined $re && $domain =~ $re))) {
> +	$_[1] =~ s#(\S*?)(([\w\.\+=\-]+)\@([\w\-]+\.[\w\.\-]+))#
> +		my ($beg, $addr, $user, $domain) = ($1, $2, $3, $4);

... what about allowing the first match to be {0,N}, where N is some not
so huge value?  It'd risk incorrectly obfuscating some really long
links, but given that it's just the HTML presentation, that seems
acceptable.