Upcoming release 10.47

[Nicholas Wilson]

Hello everyone,

I'm planning to put out a new PCRE2 release fairly soon (this month).

It's been over six months since the last release, so we're due one. There have been around 150 commits, with quite a few maintenance improvements, but not all that many user-visible changes. As I have now mostly worked through my backlog of maintenance items, I'm hoping to move onto more significant improvements in the next release in 2026.

There is one significant bugfix (a crash in the rarely-used function pcre2_callout_enumerate), and lovely new feature from Zoltan, pattern recursion with subroutine return values.

I don't think I'll do a Release Candidate: there wasn't really much feedback last time I tried that. However, the master branch is currently very close to what the final release will be, so I would welcome any testing, if you are able to update and run your test suites to validate the release ahead of time. Some PRs have yet to be merged before the release, so the code is not final or frozen.

* Let me know if you encounter problems, bugs, or changes in behaviour

* Is there anything else that should be in the release notes?

* Or indeed, anything urgent that you'd like me to do in this release, while there's a chance?

DRAFT OF NEWS FILE (subject to change...):

pcre2/NEWS at master · PCRE2Project/pcre2

DRAFT OF CHANGELOG:

pcre2/ChangeLog at master · PCRE2Project/pcre2

All the best,

Nick

[Nicholas Wilson]

I believe that all the planned changes are now completed and merged, and so in the next few days I will announce PCRE2 10.47.

There is no urgency for distributions to update.

There is still time for feedback.

Nick

[Matthew Vernon]

Hi,

On 15/10/2025 17:33, Nicholas Wilson wrote:
> I believe that all the planned changes are now completed and merged, and
> so in the next few days I will announce PCRE2 10.47.
>
> There is no urgency for distributions to update.

I'll try and get an upload to Debian's experimental distribution shortly
after the release, so our CI can build it (and see if anything else
breaks).

> There is still time for feedback.

Process-wise, no pre-release is fine for a low-impact-expect release; if
there was more concern that some changes could cause problems, a RC
would still be good.

Thanks,

Matthew

[Nicholas Wilson]

Thank you Matthew.

I am hoping that this will be a low-impact release.

There is one change which may interest package distributors in particular.

I have addressed this Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902060

PCRE2 will build shared libraries with versioned ELF symbols now by default. However, there is an option to opt out of this, so there is no urgency for distributions to adopt this immediately.

Nick

[Lukas Javorsky]

Hi Nicholas

Once the release is out, I'll work on adding it to Fedora as well.

--
You received this message because you are subscribed to the Google Groups "PCRE2 discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcre2-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pcre2-dev/cf26c531-5e82-4a19-a878-388e32dfeaedn%40googlegroups.com.

--

S pozdravom/ Best regards

Lukáš Javorský

Senior Software Engineer, Core service - Databases

Red Hat

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljav...@redhat.com

[Carlo Arenas]

Lucas,

are you also planning on backpoirting and releasing a new package for 10.46 that includes the fixes for the aarch64 JIT SIMD optimization [1] that is security [2] sensitive and release that for at least Fedora 42?

Carlo

[1] https://github.com/PCRE2Project/pcre2/pull/818
[2] https://github.com/PCRE2Project/pcre2/security/advisories/GHSA-43gg-c3xx-7w7g

[Lukas Javorsky]

Hi Carlo,

The current plan is to rebase the pcre2 to the 10.47 version in Fedora Rawhide (44) and possibly Fedora 43. 

Since Fedora 42 has been in the stable phase for some time now, I won't be releasing this new version there. If you believe we should reconsider this decision, please feel free to file a bug in our Bugzilla [1] with your justification.

[1] https://bugzilla.redhat.com/

--

You received this message because you are subscribed to the Google Groups "PCRE2 discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcre2-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pcre2-dev/fee88adf-c67c-496e-8849-8fe5bc14fa76n%40googlegroups.com.

[Carlo Arenas]

Hi Lukas, apologize from the typo in my previous message.

On Sunday, November 2, 2025 at 9:39:32 AM UTC-8 Lukas Javorsky wrote:

The current plan is to rebase the pcre2 to the 10.47 version in Fedora Rawhide (44) and possibly Fedora 43. 

That is indeed the most sensible choice, which is why I was more concerned about Fedora 42 and obviously any derived distributions.

For added context; I should mention that PCRE2 10.46 should had been probably called PCRE2 10.45.1, if we were capable of doing so[1], so unlike what we used to have before Nicholas took over maintainership from Philip ariund the release of 10.45, there are proportionally a lot more change in 10.47 when compared with 10.46, than you would see historically, and only 1 change between 10.46 and 10.45.

Which is why 10.46 whould be IMHO a good target for backported fixes, if it is meant to be used long term, and considering that the fix is very isolated backporting it to all versions that are currently supported might be even better.

 

Since Fedora 42 has been in the stable phase for some time now, I won't be releasing this new version there. If you believe we should reconsider this decision, please feel free to file a bug in our Bugzilla [1] with your justification.

will do; it might take me a little while though, as the bug is very evasive, and I am actually not sure that the issues are easily visible in Fedora, but are likely to be happening, based on the random reports of crashes in aarch64 systems that point to PCRE2 that are easy to find in support forums that next suggest to disable JIT one way or another.

alternatively, a configuration change in PHP that disables JIT by default in ARM64 systems should be IMHO recommended for all versions of PCRE2 before 10.47 (as an example of a usual setup found in the wild where these problems manifest), ot even disable JIT in the package build process.

Carlo

[1] https://github.com/PCRE2Project/pcre2/pull/771

[Nicholas Wilson]

I suppose this really highlights our lack of clear supported-version policy.

At the moment, we don't have a list of versions that we consider in-support for security backports. In my head, it's just:

* latest version only supported;

* if a (security) bug is found in the latest version I'll do an immediate release of a new version

* if a (security) bug is found in an older version we'll tell people to upgrade

This obviously doesn't really work for linux distributions with stable versions that must be supported for many years.

Perhaps we should instead consider providing a "lowest supported version" based on what distros are currently requiring support for.

* all versions since the lowest supported will have maintainer-provided backported fixes

* each PCRE2 release that has any fixes with security implications will be released with an accompanying patch for each affected version within support

* those old versions would then effectively get a growing list of upstream-supported patches

Instead of patches (diffs), I could even do a full patch release for each and every supported version. (Ouch.)

This would be much more work for us though. On the other hand, each distro's maintainers are (nominally) doing this work already.

Some data:

* RHEL 8 is in support with PCRE2 10.32 (ouch); RHEL 9 has 10.40

* Debian oldstable (bookworm) has 10.42

* Ubuntu 22.04 LTS (Jammy) has 10.39

I'm not sure what the right approach is, or what distros would prefer for their workflows.

I'm a bit surprised by how willing distros seem to be to distribute upstream releases with their own private patches.

What thoughts do people have?

Nick

[Carlo Arenas]

On Monday, November 3, 2025 at 10:06:55 AM UTC-8 Nicholas Wilson wrote:

I suppose this really highlights our lack of clear supported-version policy.

I violently agree; we had an implicit supported-version policy before 10.46, and isince it was implicit, it was also not very consisently understood. We also had (with the exception of 10.45) never been successful IMHO in using the community resources available to us to ensure a "successful". release, which meant we ended up having "lucky" releases which are solid and that some distributors decided to "fork" for their own stable trees, and some unlucky ones that were quickly followed by a "brown bag" release.

Backporting "fixes" was always meant to be a distribution issue under that policy, For example, there is a known bug in the PCRE2 version in Ubuntu 20.04 that needs to have a workaround put on place in the user of that library codebase as explained in this[1] comment.

The only fix we provided was: " upgrade your library to 10.36 or newer, or at your own leasure backport this patch[2]", "affects 10.34 or newer",

At the moment, we don't have a list of versions that we consider in-support for security backports. In my head, it's just:

* latest version only supported;

* if a (security) bug is found in the latest version I'll do an immediate release of a new version

* if a (security) bug is found in an older version we'll tell people to upgrade

This obviously doesn't really work for linux distributions with stable versions that must be supported for many years.

That is an interpretation of that "implicit" policy and is indeed what was made explicit (but probably clarified to distributors) and leads to 10.46 being so special.

 

Perhaps we should instead consider providing a "lowest supported version" based on what distros are currently requiring support for.

* all versions since the lowest supported will have maintainer-provided backported fixes

* each PCRE2 release that has any fixes with security implications will be released with an accompanying patch for each affected version within support

* those old versions would then effectively get a growing list of upstream-supported patches

Instead of patches (diffs), I could even do a full patch release for each and every supported version. (Ouch.)

This would be much more work for us though. On the other hand, each distro's maintainers are (nominally) doing this work already.

This most likely will also require us to add a third digit version number, which will also add its own compatibility issues, but that should be feasible IMHO.

  

[1] https://github.com/PCRE2Project/pcre2/issues/51#issuecomment-1079666191

[2] https://github.com/PCRE2Project/pcre2/commit/e0c6029.patch

[Matthew Vernon]

Hi,

It's been good that pcre2 has had a very low number of security issues :)

On 03/11/2025 18:06, Nicholas Wilson wrote:

> * Debian oldstable (bookworm) has 10.42

Debian oldoldstable (bullseye) has 10.36+deb11u1, which is 10.36 plus
backporting (by myself IIRC) of the fixes to CVE-2022-1586 &
CVE-2022-1587; but it's now managed by the Debian LTS team rather than
the regular security team.

> I'm a bit surprised by how willing distros seem to be to distribute
> upstream releases with their own private patches.

Debian's approach to security problems in stable is to always prefer the
minimum-possible-change to fix the bug[0]; so we will (almost) always
prefer to backport the bugfix onto the version that shipped in stable,
and try to avoid any API/ABI change.

I uploaded 10.46 to trixie (as 10.46-1~deb13u1) to fix CVE-2025-58050
because it was an upstream bugfix release, so the change from 10.45 was
minimal.

From a distribution point of view, it's great if upstream backport
security fixes to relevant vulnerable versions because I'm very
lazy^W^W^W you're much more expert in the code than I am (especially if
the backport isn't trivial), but if not then a clear idea of when the
bug was introduced (and ideally a reproducer so I can test a backported
fix) is helpful.

Regards,

Matthew

[0]
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#preparing-packages-to-address-security-issues

[Nicholas Wilson]

Thank you Matthew, that's helpful.

I've gathered yet more information on version numbers used in the wild.

These are the versions of PCRE2 which are shipped by versions of Linux distros that are still in support.

Debian 11 bullseye: 10.36
Debian 12 bookworm: 10.42
Debian 13 trixie: 10.46

20.04 Focal: 10.34
22.04 Jammy: 10.39
24.04 Noble: 10.42
25.04 Plucky: 10.45
25.10 Questing: 10.46

(also related - Fedora, CentOS)
8 RHEL: 10.32
9 RHEL: 10.40
10 RHEL: 10.44

Alpine 3.20: 10.43
Alpine 3.21: 10.43
Alpine 3.22: 10.46

SUSE 15: 10.39

Arch: no support cycle

So, in theory, someone somewhere (for at least one distro) is still supporting the following PCRE2 versions:
32, 34, 36, 39, 40, 42, 43, 44, 45, 46
Versions that seem not to be used:
33, 35, 37, 38, 41

Anything at 10.35 or earlier is older than 5 years

Proposed policy: PCRE2 releases will be supported for 5 years.

* One exception will be made for RHEL. Just be aware they last longer in the wild than anyone else.

* Matching the 10+ years of "extended support" for RedHat and SUSE is just too much for me.

* For releases that are not the latest-and-greatest PCRE2, I will publish a "lifecycle advice" file along with each new PCRE2 release

* The advice will list the versions I consider to still be in-support, and advice on how to use them.

* This will consist of a list of blessed backported patches or build instructions

* eg "10.39 is in-support, but we recommend the following two patches ..."

* eg "10.46 is a drop-in replacement for 10.45; do not ship 10.45"

* If serious bugfixes or security fixes are made in a new PCRE2 release, the lifecycle advice file may add new advised patches for stable distros

Proposed status of in-support releases:
10.32 - older than 5 years but in RHEL 8
10.36
10.37
10.38 - do not use (update to 10.39)
10.39
10.40
10.41 - do not use (update to 10.42)
10.42
10.43
10.44
10.45 - do not use (update to 10.46)
10.46
10.47

Some maintainer homework for me:

* Crawl through all the CVEs and PCRE2's NEWS and ChangeLog files

* Hunt through packaging files for all of Debian/Fedora/CentOS/Alpine/SUSE/Arch/etc and identify all the backported patches that distributors are actually using

* Then I aspire to actually build this "lifecycle advice file".

The goal would be that if two different stable/LTS distros both ship 10.39 (say), there should be a simple way for maintainers to use the same backported patches.

It sounds like quite a bit of work though. Most libraries probably just forget about their old releases; or else maintain several parallel branches and do point releases on each branch whenever there's a significant bugfix.

All the best,

Nick

[Lukas Javorsky]

Thank you, Nick, for all the work.

Can you just please explain what you mean by the exception here?:

> * One exception will be made for RHEL. Just be aware they last longer in the wild than anyone else.

To clarify the RHEL situation, we generally do not rebase once RHEL is released. This is due to the API/ABI compatibility we want our customers to enjoy.

This means that we need to backport quite often as a cost of this approach.

If you have any questions you'd like to ask me (as the maintainer for Fedora/CentOS Stream/RHEL), feel free to ask. We can discuss them even off the list to avoid overwhelming others. :)

--

You received this message because you are subscribed to the Google Groups "PCRE2 discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pcre2-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pcre2-dev/fca7c779-41dc-498f-8bc5-7909b716555cn%40googlegroups.com.

[Nicholas Wilson]

> To clarify the RHEL situation, we generally do not rebase once RHEL is released. This is due to the API/ABI compatibility we want our customers to enjoy.
This means that we need to backport quite often as a cost of this approach.

Exactly. Once RHEL is released with PCRE version X, then version X must be supported by you or us for the full 5 (or even 10) years. You can't make people on RHEL 8 or 9 or 10 move to a newer version of PCRE2.

So, the "exception" is that while I could see myself committing to providing backports for all security issues, going back to all PCRE2 releases in the last 5 years, I'd probably need to additionally support the specific version shipped in RHEL which is older than 5 years but still within support.

I don't really want to be backporting fixes to every single PCRE2 version from the last 10 years. But I could manage 4 or 5 years, plus the extra/exceptionally-supported version needed by RHEL.

Does that make sense?

Nick

[Lukas Javorsky]

Yes, thank you for clarifying.

As you say, the cost is the burden of backporting. In such cases, please reach out to me, and we can try to help as well (surely with your assistance as the expert).

To view this discussion visit https://groups.google.com/d/msgid/pcre2-dev/650faabc-e056-46e7-b025-3a64b0808412n%40googlegroups.com.