[Privoxy-devel] pcre2 support

Fabian Keil fk at fabiankeil.de
Sun Nov 28 10:25:18 UTC 2021


Roland Rosenfeld <roland at spinnaker.de> wrote on 2021-11-26:

> On Mi, 24 Nov 2021, Fabian Keil wrote:
> 
> > On the TODO list there is:
> > | 79) Evaluate pcre alternatives.
> > https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=TODO;hb=HEAD#l180
> > 
> > I consider pcre2 an alternative but there are others
> > and I'm not familiar enough with them to quickly decide
> > if they are better or worse for our purposes.
> > 
> > Maybe migrating to pcre2 is less work but at the moment
> > but I'm not sure about this either.
> 
> As an active Perl user, I prefer perl regular expressions over other
> (posix and the like) regexp.  I think that pcre/pcre2 currently is the
> most common perl regex library, which may imply that it is the most
> secure one.

I'm an active Perl user as well but my assumption is that some
of the other regex libraries support somewhat Perl-compatible
regular expressions as well.

I agree that pcre and pcre2 may have less security issues than
the other libraries.

> > > Debian is planning to remove the classic pcre (8.39) library in
> > > the next release (Bookworm) and substitute it by pcre2.
> > 
> > Is there a time frame?
> 
> In https://bugs.debian.org/999981 the Debian maintainer of pcre as
> well as pcre2 writes, that he "like to remove the pcre3 libraries from
> Debian, preferably in time for the release of Bookworm."
> At the moment, there is no schedule for bookworm release, but I expect
> bookworm to be frozen around the end of 2022.

Interesting.

> Currently there are 212 Debian source packages using the old pcre
> library, I have no idea, whether all can be changed before Bookworm
> release.  Depending on the bottom not migrated early enough, packages
> may be removed from Bookworm or the old pcre library may stay until
> the next release.

I just checked the reverse dependencies on my Laptop
(this only checks packages I have actually installed
and only works if the library isn't linked statically):

fk at t520 ~ $pkg info -r pcre-8.45
pcre-8.45:
	rasqal-0.9.33_1
	i3-4.20.1
	glib-2.70.1,2
	cppcheck-2.5
fk at t520 ~ $pkg info -r pcre2-10.39
pcre2-10.39:
	qemu-5.0.1_2
	vte3-0.64.2
	qt5-core-5.15.2_5

Privoxy doesn't show up because it's running in a jail.

> Anyway we should try to migrate away from the obsolete library in the
> long term...

Indeed.

> > Is python 2.7 already gone?
> 
> No, but I'm happy with every piece of software that is migrated to
> python 3 and does no longer depend on 2.7, since it's no secure
> feeling if you use software, that depends on libraries that have no
> security support any more.
> 
> > It's still part of the FreeBSD ports even though it was
> > supposed to expire on 2020-12-31, nearly a year ago.
> > 
> > Due to applications like Mailman (which we also use for
> > the Privoxy mailing lists) it hasn't been deleted yet.
> 
> Debian replaced mailman by mailman3 (using Python 3) in Debian buster
> (which was release in July 2019)...

My understanding is that Mailman 3.x still lacks lots of
features that are supported by Mailman 2.x.

The FreeBSD project migrated away from Mailman completely.

> > > So since pcre1 is now obsolete, it may be a good idea to migrate
> > > privoxy to pcre2...
> > 
> > I agree that it could be a good idea but it's not clear to
> > me how much time we have left.
> >
> > At the moment I'm still sitting on a couple of other patches
> > that I have to send to Ian for review so I can get the money
> > from our SPI account.
> > 
> > I hope to be able to get this done soonish,
> > hopefully before the end of the year.
> 
> That would be great, I'd really appreciate that.  That would be enough
> time to intensively test the change and bring it into Bookworm.
> 
> I had a look at the code myself and most pcre code is collected in
> pcrs.[ch], but to say the truth, my C skills are too limited to
> rewrite pcrs using pcre2 myself and I'm not sure, whether completely
> replacing pcrs with the new pcre2_substitute API would be the
> preferable way (but I fear that's much more work).

Instead of rewriting pcrs we should probably add another pcrs
implementation so users can change at configure time which
pcre version they want to use.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20211128/7700e794/attachment.bin>


More information about the Privoxy-devel mailing list