unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Kyle Meyer <kyle@kyleam.com>
Cc: meta@public-inbox.org
Subject: Re: archive links broken with obfuscate=true
Date: Fri, 9 Apr 2021 23:37:00 +0000	[thread overview]
Message-ID: <20210409233700.GA11190@dcvr> (raw)
In-Reply-To: <87zgy7rs9q.fsf@kyleam.com>

Kyle Meyer <kyle@kyleam.com> wrote:
> 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.

Thanks for the report.  Have you run any performance tests?

> > 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] // '&#8226;';
> >  	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.

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...

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?).

OTOH, it may not be an actual problem at all and I'm just
confusing this with something else.

  reply	other threads:[~2021-04-09 23:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09  2:11 archive links broken with obfuscate=true Kyle Meyer
2021-04-09 10:21 ` Eric Wong
2021-04-09 22:45   ` Kyle Meyer
2021-04-09 23:37     ` Eric Wong [this message]
2021-04-10  4:06       ` Kyle Meyer
2021-04-10  5:15         ` Eric Wong
2021-04-10 19:49           ` Kyle Meyer
2021-04-11  5:32             ` [PATCH v2] www: do not obfuscate addresses in URLs Eric Wong
2021-04-11  5:34               ` Eric Wong
2021-04-11 14:45               ` Kyle Meyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210409233700.GA11190@dcvr \
    --to=e@80x24.org \
    --cc=kyle@kyleam.com \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).