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] // '•';
> > 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.
next prev parent 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).