PCRE2 support?

Thomas Ward teward at thomas-ward.net
Thu Jan 24 15:23:01 UTC 2019


It's been several more months, but now I need to ask what distributions
you are 'supporting' here, Maxim and nginx team.

PCRE2 is in Debian, Ubuntu, CentOS, Fedora, and others.  That covers a
large portion of the major distributions at play.

This has once again popped on my radar in Ubuntu as we are trying to
move pcre3 out of Main, and rely on pcre2.  NGINX is one of the few
packages that hasn't had any changes to it to make it PCRE2-supportable.

I also agree that Exim should not be the basis of support.


Is it possible to revisit this decision, and determine whether it is
possible to support PCRE2 as it is now 2019 and many things seem to be
switching to pcre2?  Otherwise, we have to either

(1) Strip out PCRE support entirely in NGINX in Ubuntu, which would
break most if not all regex functionality.

(2) No longer consider nginx supported officially and drop it to
community-only support (which means I will be once again doing all the
work in Ubuntu to patch it, though this isn't new for me).


I would like to ask that this be re-discussed and revisited since PCRE2
is far from 'new' and many things're switching to it, as well as it
being present in multiple major distributions now.


Thomas


On 9/19/18 3:19 AM, Mark Mielke wrote:
> On Tue, Sep 18, 2018 at 11:55 AM Maxim Dounin <mdounin at mdounin.ru
> <mailto:mdounin at mdounin.ru>> wrote:
>
>     On Tue, Sep 18, 2018 at 08:12:20AM -0400, Thomas Ward wrote:
>     > Downstream in Ubuntu, it has been proposed to demote pcre3 and
>     > use pcre2 instead as it is newer.
>     > https://trac.nginx.org/nginx/ticket/720 shows it was marked 4
>     > years ago that NGINX does not support pcre2.  Are there any
>     > plans to use pcre2 instead of pcre3?
>     There are no immediate plans.
>     When we last checked, there were no problems with PCRE, but PCRE2
>     wasn't available in most distributions we support, making the
>     switch mostly meaningless.
>
>
> I think there have been changes since then. PCRE2 was new in 2015, but
> isn't new in 2018.
>
> RHEL 7 (and clones) include libpcre2. I think this is a pretty wide
> set of machines right here. I believe Ubuntu 16.04 LTS has libpcre2
> which is another wide set. Fedora has had it for a while now. I think
> that unless you go to older releases, all major distributions should
> have PCRE2 by now.
>
> I build haproxy with PCRE2 support.
>
> One that was interesting to me, is that Git recently (April, 2018?)
> switched to building with PCRE2 by default when "USE_LIBPCRE=Yes" was
> specified:
>
> https://github.com/git/git/commit/cac5351363c5713248b8494e1e58e282c0a5bde7
>
> I'm not sure about meaningless from a functionality perspective. All
> new features are going into PCRE2. PCRE is a stable branched with only
> bug fixes and security problems fixed. The newest features, including
> performance improvements, are all in PCRE2. I believe the reason it is
> "PCRE2-10" instead of "PCRE-10", is because of API changes, and the
> opportunity to improve or fix previous API decisions. This then
> becomes the basis for all future development free of the PCRE API
> shackles.
>
>  
>
>
>     Also, it looks like PCRE2 is still not supported even by Exim,
>     which is the parent project of PCRE and PCRE2:
>
>     https://bugs.exim.org/show_bug.cgi?id=1878
>
>
> I don't think Exim should be the measure:
>
> "PCRE was originally written for the Exim MTA <https://www.exim.org/>,
> but is now used by many high-profile open source projects,
> including Apache <https://httpd.apache.org/>, PHP
> <http://www.php.net/>, KDE <https://www.kde.org/>, Postfix
> <http://www.postfix.org/>, and Nmap <https://nmap.org/>. PCRE has also
> found its way into some well known commercial products, like Apple
> Safari <https://www.apple.com/safari/>. Some other interesting
> projects using PCRE include Chicken
> <http://www.call-with-current-continuation.org/>, Ferite
> <http://www.ferite.org/>, Onyx
> <http://www.canonware.com/onyx/>, Hypermail
> <http://www.hypermail-project.org/>, Leafnode
> <http://leafnode.sourceforge.net/>, Askemos
> <http://www.askemos.org/>, Wenlin <http://www.wenlin.com/>, and 8th
> <http://8th-dev.com/>."
>
> This list is also far from complete. PCRE and PCRE2 are widely used,
> and PCRE2 is where all current improvement is occurring. Anybody
> waiting for Exim, will probably be among the very last to switch.
>
>
>     As such, adding PCRE2 support to nginx looks premature.
>
>
>
> Before writing the above, I was debating with myself about when the
> right time to add support for a new component release is. For some
> projects and some components, it will be more important than others.
> For example, OpenSSL 1.1.1 with TLSv1.3 support might be considered
> premature for some projects to support, and yet Nginx supports this
> newly released version long before OpenSSL 1.1.1 is readily available
> in a majority of distributions that you support. I think in this case,
> OpenSSL 1.1.1 is of strategic importance to Nginx, and this ensured it
> was on the roadmap. (However, it still seems to be missing an ability
> to configure the cipher suite... :-) )
>
> I don't know if PCRE2 belongs on this roadmap. I think there have been
> significant improvements with the JIT compilation that could prove
> useful for higher performance evaluation of regular expressions with
> Nginx, but I personally don't have this requirement, so if after
> considering all of the above - you still felt it was premature, I
> wouldn't raise any concern personally. I just want to make sure this
> is an informed position. :-)
>
> -- 
> Mark Mielke <mark.mielke at gmail.com <mailto:mark.mielke at gmail.com>>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20190124/7ec796e2/attachment.html>


More information about the nginx-devel mailing list