Bug#1001416: ITP: libvmod-re2 -- RE2 regular expressions for Varnish
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer <fladi@debian.org>
X-Debbugs-Cc: debian-devel@lists.debian.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
* Package name : libvmod-re2
Version : 1.11.0
Upstream Author : 2016, UPLEX Nils Goroll Systemoptimierung
* URL : https://code.uplex.de/uplex-varnish/libvmod-re2
* License : BSD-2-clause
Programming Lang: C
Description : RE2 regular expressions for Varnish
Varnish Module (VMOD) for access to the Google RE2 regular expression
engine. Varnish VCL uses the PCRE library (Perl Compatible Regular Expressions)
for its native regular expressions, which runs very efficiently for many
common uses of pattern matching in VCL, as attested by years of
successful use of PCRE with Varnish.
.
But for certain kinds of patterns, the worst-case running time of the
PCRE matcher is exponential in the length of the string to be matched.
The matcher uses backtracking, implemented with recursive calls to the
internal match() function. In principle there is no upper bound to the
possible depth of backtracking and recursion, except as imposed by the
varnishd runtime parameters pcre_match_limit and
pcre_match_limit_recursion; matches fail if either of these limits are
met. Stack overflow caused by deep backtracking has occasionally been
the subject of varnishd issues.
.
RE2 differs from PCRE in that it limits the syntax of patterns so that
they always specify a regular language in the formally strict sense.
Most notably, backreferences within a pattern are not permitted, for
example (foo|bar)\1 to match foofoo and barbar, but not foobar
or barfoo. See the link in SEE ALSO for the specification of RE2
syntax.
.
This means that an RE2 matcher runs as a finite automaton, which
guarantees linear running time in the length of the matched string.
There is no backtracking, and hence no risk of deep recursion or stack
overflow.
I intend to maintain this package as part of the Varnish Packaging Team.
-----BEGIN PGP SIGNATURE-----
iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmGyZm8RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpH3Qf/e8G/P2Ezny0BkeLub+m1i2RbZxuUpZwU
Ry8UkSbkpU0oMvRsJ6kEqen2YEe9oeD0zm4t5pOGl51XWNOpr8M+7fZr0Vu0cNCw
nbKoN41Jaot+nHdYxNiPhkOOcYBK8gcsbeDuB87JXfx4V1l5VfL5bfcU3yiKqEE+
vgYRXx2EFiDsiXXtpxd/sh9rCMfB8Pvky7KFfIMk8sbK0rFPDHbDs4azCkXEqB8g
LUFnSCqnqL5oApo3CjFxE7GO3PqcUJhzsQP38HS9d7WLdiaJQsVC88pxMYxodJFQ
vTXTXK+CffHaYYA7smO93I7fyX1XGJZ1L3UQ1j+OqfQaDC/OaVF1IQ==
=qqVV
-----END PGP SIGNATURE-----
Reply to: