-
Notifications
You must be signed in to change notification settings - Fork 241
Description
Following enquiries, I would like to firm up some sort of support policy for PCRE2, reflecting the fact that Linux distributions have releases shipping old versions of PCRE2.
For security and serious bugfixes, the support policy should indicate a clear action to take for distributors shipping older versions. Ideally, all long-term-support distros shipping version N of PCRE2 would be able to make use of a shared set of patch files. Individual downstream maintainers should not have to guess what actions they need to take to ship a secure version of PCRE 10.39 (for example).
The policy shall be, "each PCRE2 version to be supported for 5 years from release; plus perhaps selected older releases still in active circulation". RHEL/CentOS is the major distribution which ships very old versions.
Major distributions to track
Based on market share (guessed). Also, we can ignore distributions which do not package PCRE2 themselves, but are simply derivative from another upstream Linux distribution.
- RHEL/CentOS/Fedora. One package source; versions trickle down. Stays in the wild for a very, very long time. PCRE2 versions already a year old or older by the time they go into RHEL/CentOS, and then stay supported a further five years.
- Debian - five years LTS
- Ubuntu - do they simply use Debian packages, or make their own?
- Alpine - two years (many or most Docker images)
- SUSE - eye-wateringly long. Their USP appears to be, "pay us and we'll let you get a compliance stamp of approval on never updating your servers". (Maybe that's a bit harsh.)
- Arch - rolling support. But they're an upstream for many distros.
New artifact
Each release of PCRE2 from now on to be accompanied by SUPPORT-LIFECYCLE.md file
This file lists each release of PCRE2 less than five years old, plus the one shipping in RHEL (RHEL 8).
For each PCRE2 release:
- Either it is not supported; a guaranteed drop-in compatible release is given. Eg "10.46 is a drop-in replacement for 10.45; do not ship 10.45"
- Or, the release is given along with a list of blessed & tested backports of fixes. Eg "10.39 is in-support, but we recommend the following two patches ..."
If serious bugfixes or security fixes are made in a new PCRE2 release, the lifecycle advice file may add new advised patches for older releases, as well as correcting those bugs in the new release, offering a choice of mitigations to users (upgrade to new release; or apply blessed patch to old release).
A possible naming scheme for these backported fixes could be PCRE2 "10.39-backport-10.48" for "PCRE2 10.39 with the patches specified by SUPPORT-LIFECYCLE.md from PCRE2 10.48".
Current list of releases which will be supported as of 10.48
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".