https://fedoraproject.org/wiki/PcreDeprecation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavorsk@redhat.com
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
The new 'pcre2' package is out for more than 7 years now and most of the packages have already been ported to its redefined API. [https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html Mail] about the changes in the pcre2.
=== Plan === 1) File the BZ trackers for all of the dependent packages.
2) Document the deprecation.
3) Start the [[PcreRetirement|new change]] with the pcre retirement.
== Feedback == The early feedback from the community is in [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... this mailing thread]
== Benefit to Fedora == Fedora shouldn't support unsupported packages. When the future RHEL versions fork from Fedora, it could lead to less secure RHEL as well. By deprecating this package, we will send the message to the maintainers that their packages should port to new pcre2 package and any new package would have to use only new and supported pcre2 version.
== Scope == * Proposal owners: 3 steps mentioned in the [https://fedoraproject.org/wiki/PcreDeprecation#Plan Plan].
* Other developers: Port their package to support the new pcre2. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives:
== Upgrade/compatibility impact == The old pcre package will be deprecated, so the new packages are not able to require it and have to require the new pcre2 version of this package.
== User Experience == Users will not be exposed to the possible vulnerable pcre package, because the pcre2 is supported by the upstream community.
== Dependencies == This list is obtained by using and combining the output of the following commands:
dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires 'libpcre.so.1()(64bit)' --whatrequires 'libpcreposix.so.0()(64bit)' -s | pkgname
dnf repoquery --disablerepo='*' --enablerepo=rawhide-source --whatrequires pcre-devel | pkgname
=== List ===
*389-ds-base *adanaxisgpl *aide *aircrack-ng *anope *apachetop *bti *ccze *cegui *cegui06 *clamav *ClanLib *clisp *clover2 *coccinelle *collada-dom *compton *condor *cppcheck *cyrus-imapd *deepin-file-manager *dogtag-pki *EMBOSS *eterm *Falcon *freeradius *gambas3 *ganglia *ghc-highlighting-kate *ghc-pcre-light *ghc-regex-pcre *GMT *gnote *golang *gource *grep *groonga *gsmartcontrol *haxe *hydra *hyperscan *i3 *i3-gaps *imapfilter *Io-language *kdelibs *kdelibs3 *kdevelop *kf5-kjs *kf5-kplotting *libast *liblognorm *libmodsecurity *lnav *logstalgia *lumail *medusa *mle *mod_auth_openid *mod_auth_openidc *mod_qos *mod_security *monotone *ncid *nekovm *ngrep *nmap *ocaml-pcre *oci-umount *octave *openCOLLADA *openscap *opensips *pads *pcre *pdfgrep *perl-re-engine-PCRE *petsc *php-pecl-apcu *php-pecl-http *php-pecl-oauth *picom *pl *poco *postgis *powwow *prelude-lml *privoxy *proxysql *python-qutepart *python-scss *R *rasqal *regexxer *remctl *renderdoc *rkward *root *rudiments *sigil *slang *sord *sslh *suricata *sway *swig *syncevolution *syslog-ng *the_foundation *the_silver_searcher *Thunar *tin *tintin *tinyfugue *trafficserver *uwsgi *vdr-epgfixer *watchman *wireshark *wmweather+ *xastir *xfce4-verve-plugin *xgrep *xmlcopyeditor *zsh
== Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not needed for this Change) * Contingency deadline: N/A (not needed for this Change) * Blocks release? No
== Documentation ==
There should be documentation of this change, so the users know that the pcre is no longer supported and cannot be required by any Fedora package. If an existing package requires the pcre package, it is considered as a bug.
== Release Notes == Release notes should contain the information about the pcre deprecation so the users know they won't be able to use its libraries anymore.
Ben Cotton wrote:
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner ==
- Name: [[User:ljavorsk| Lukas Javorsky]]
- Email: ljavorsk@redhat.com
This is simply a non-starter.
You yourself list dozens of packages using this compatibility library. Some of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and will never be fixed by upstream. It is entirely impractical to port them to a completely different API. But even current leaf packages such as rkward are in the list.
PCRE 1 needs to remain as a fully supported compatibility library for the foreseeable future.
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
How different is the code from the pcre2 code? If it is completely different, then CVEs found in pcre2 will typically not affect the legacy code, and you can expect a steep drop in found CVEs with the upstream drop of support. If, on the other hand, it is sufficiently similar for the CVEs to apply, then the fixes can also be backported.
In the end, my suggestion if you are unable to deal with the security vulnerabilities is to simply orphan the library and let someone else pick it up. (If nobody else does, I will, because at least 3 of my packages depend on it.)
Kevin Kofler
On Wed, Aug 24, 2022 at 3:14 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
...
This is simply a non-starter.
...
PCRE 1 needs to remain as a fully supported compatibility library for the foreseeable future.
...
In the end, my suggestion if you are unable to deal with the security vulnerabilities is to simply orphan the library and let someone else pick it up. (If nobody else does, I will, because at least 3 of my packages depend on it.)
And thank you for volunteering. This is the obvious way forward in a volunteer community.
I would, of course, recommend you request upstream commit access to support PCRE1 going forward, as (clearly) more than just Fedora will benefit from someone willing to take on such support.
Thanks!
On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
Ben Cotton wrote:
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner ==
- Name: [[User:ljavorsk| Lukas Javorsky]]
- Email: ljavorsk@redhat.com
This is simply a non-starter.
You yourself list dozens of packages using this compatibility library. Some of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and will never be fixed by upstream. It is entirely impractical to port them to a completely different API. But even current leaf packages such as rkward are in the list.
PCRE 1 needs to remain as a fully supported compatibility library for the foreseeable future.
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
How different is the code from the pcre2 code? If it is completely different, then CVEs found in pcre2 will typically not affect the legacy code, and you can expect a steep drop in found CVEs with the upstream drop of support. If, on the other hand, it is sufficiently similar for the CVEs to apply, then the fixes can also be backported.
pcre will also have a drop in found CVEs simply because far fewer people will be bothering to look at the old code. If no one is looking for bugs then none are going to be reported :-) The number of CVEs (fixed or not) as a metric on its own, tells us little about the security quality of any package.
With regards, Daniel
Daniel P. Berrangé wrote:
pcre will also have a drop in found CVEs simply because far fewer people will be bothering to look at the old code. If no one is looking for bugs then none are going to be reported :-)
That was exactly my point though. If nobody finds CVEs, then nobody has to fix them. We can only fix what we know about, and blackhats can only attack what they know about.
Kevin Kofler
On Wed, Aug 24, 2022, at 11:56, Kevin Kofler via devel wrote:
That was exactly my point though. If nobody finds CVEs, then nobody has to fix them. We can only fix what we know about, and blackhats can only attack what they know about.
The fact that there are no new CVEs (and therefore fixes) does not imply that there are no security vulnerabilities (potentially) exploited in the wild.
On 8/24/22 05:56, Kevin Kofler via devel wrote:
Daniel P. Berrangé wrote:
pcre will also have a drop in found CVEs simply because far fewer people will be bothering to look at the old code. If no one is looking for bugs then none are going to be reported :-)
That was exactly my point though. If nobody finds CVEs, then nobody has to fix them. We can only fix what we know about, and blackhats can only attack what they know about.
Evil hackers will not stop looking for flaws in a package just because it is no longer supported. The correct response is to port the impacted packages to use PCRE2, either directly or via a wrapper library.
On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
Ben Cotton wrote:
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner ==
- Name: [[User:ljavorsk| Lukas Javorsky]]
- Email: ljavorsk@redhat.com
This is simply a non-starter.
"non-starter" is not the phrase you are looking for. This change is explicitly about *deprecating* the package to encourage packagers to move off the dependency and not add any new dependencies. This is something that we certain *can do*, and something that'll benefit the distro.
What we do with the package two years down the road when as many dependencies as possible have been removed, is a separate topic, subject to the (at this point hypothetical) second Change proposal. So… hold your guns unless you have issues with *this* part, i.e. deprecation.
You yourself list dozens of packages using this compatibility library. Some of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and will never be fixed by upstream. It is entirely impractical to port them to a completely different API. But even current leaf packages such as rkward are in the list.
PCRE 1 needs to remain as a fully supported compatibility library for the foreseeable future.
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
How different is the code from the pcre2 code? If it is completely different, then CVEs found in pcre2 will typically not affect the legacy code, and you can expect a steep drop in found CVEs with the upstream drop of support. If, on the other hand, it is sufficiently similar for the CVEs to apply, then the fixes can also be backported.
In the end, my suggestion if you are unable to deal with the security vulnerabilities is to simply orphan the library and let someone else pick it up. (If nobody else does, I will, because at least 3 of my packages depend on it.)
That is always an option. I think the porting effort depends a lot on what parts of the pcre api are used. So let's figure out first what can be ported, and of the things that can't, what can be dropped.
Zbyszek
Thank you for all of your feedback.
As Zbyszek mentioned, this change is only about the *deprecation*, not the *retirement*. This means that if the pcre is deprecated, no new package will be allowed to require it. Also, it would mean that all of the existing packages will be notified about this deprecation and will be encouraged to port to the new pcre2 library.
However, if some package has a solid justification for not porting to the new pcre2 package, it is fine. In the event that this deprecation is approved, the next step will determine whether the package will be retired completely or orphaned and supported by some maintainers.
Anyway, the main idea behind this change is to prevent any new packages coming to Fedora 38 to require the old pcre package and forward them to use the newer version of it *pcre2*.
Lukas
On Wed, Aug 24, 2022 at 9:38 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
Ben Cotton wrote:
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner ==
- Name: [[User:ljavorsk| Lukas Javorsky]]
- Email: ljavorsk@redhat.com
This is simply a non-starter.
"non-starter" is not the phrase you are looking for. This change is explicitly about *deprecating* the package to encourage packagers to move off the dependency and not add any new dependencies. This is something that we certain *can do*, and something that'll benefit the distro.
What we do with the package two years down the road when as many dependencies as possible have been removed, is a separate topic, subject to the (at this point hypothetical) second Change proposal. So… hold your guns unless you have issues with *this* part, i.e. deprecation.
You yourself list dozens of packages using this compatibility library.
Some
of those are themselves compatibility libraries (e.g., kdelibs 3 and 4)
and
will never be fixed by upstream. It is entirely impractical to port them
to
a completely different API. But even current leaf packages such as
rkward
are in the list.
PCRE 1 needs to remain as a fully supported compatibility library for
the
foreseeable future.
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
How different is the code from the pcre2 code? If it is completely different, then CVEs found in pcre2 will typically not affect the legacy code, and you can expect a steep drop in found CVEs with the upstream
drop
of support. If, on the other hand, it is sufficiently similar for the
CVEs
to apply, then the fixes can also be backported.
In the end, my suggestion if you are unable to deal with the security vulnerabilities is to simply orphan the library and let someone else
pick it
up. (If nobody else does, I will, because at least 3 of my packages
depend
on it.)
That is always an option. I think the porting effort depends a lot on what parts of the pcre api are used. So let's figure out first what can be ported, and of the things that can't, what can be dropped.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Lukas Javorsky wrote:
Anyway, the main idea behind this change is to prevent any new packages coming to Fedora 38 to require the old pcre package and forward them to use the newer version of it *pcre2*.
As I have stated several times, I do not see this process as a productive or useful thing to do. It can prevent useful software from going into Fedora just because it has been written by upstream some time ago and not immediately packaged. It will not magically port any software to newer libraries, just prevent it from entering Fedora for no good reason.
To put it bluntly, I believe package deprecation should not exist or be allowed at all.
Kevin Kofler
On Tue, Aug 23, 2022 at 03:42:30PM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/PcreDeprecation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Upstream stopped the support for the old 'pcre' package. It only supports the new 'pcre2' version, so Fedora should deprecate it so it could later be retired and removed from Fedora entirely.
== Owner ==
- Name: [[User:ljavorsk| Lukas Javorsky]]
- Email: ljavorsk@redhat.com
== Detailed Description == Upstream stopped supporting the old 'pcre' package. The 8.45 is marked as a final release and nothing else will be added/fixed in it. This may lead to some unresolved CVEs, which would have to be resolved by the maintainers. Unfortunately, due to our limited capacity, we wouldn't have the time and experience to solve this by ourselves, so we need to deprecate this package. After the deprecation is done, the very next step would be starting the [[PcreRetirement|retirement change]], so the package is removed from Fedora entirely.
The new 'pcre2' package is out for more than 7 years now and most of the packages have already been ported to its redefined API. [https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html Mail] about the changes in the pcre2.
snip
== Benefit to Fedora == Fedora shouldn't support unsupported packages.
That's an overly broad statement that does not reflect any Fedora rule / guideline on package inclusion.
Only version large projects have stable maint streams of their releases, most upstreams only "support" the most recent release they've made. IOW if the distro isn't shipping the most recent release then it is effectively shipping unsupported packages.
For Fedora at least if a maintainer frequently rebases to new releases, they only end up supporting an unsupported package for upto about 1 year (two stable releases). RHEL is much worse, as by the time a RHEL release goes EOL, you can consider the vast majority of software to be "unsupported" from the POV of the upstream projects.
IOW, it is reasonable to say that one of the core jobs of a distro [maintainer] is often to provide support for a package that upstream no longer supports.
The issue is really about how long the distro maintainer is willing to prolong that effort on a case by case basis.
Not wishing to support multiple versions of a package in parallel is a reasonable desire for a single maintainer, to reduce their workload. It is not inherantly wrong for Fedora more generally though to want to ship and support something that upstream has stopped supporting. There just needs to be some use case for it to exist, and a maintainer willing todo the work.
versions fork from Fedora, it could lead to less secure RHEL as well. By deprecating this package, we will send the message to the maintainers that their packages should port to new pcre2 package and any new package would have to use only new and supported pcre2 version.
With regards, Daniel
-
Ben Cotton -
Daniel P. Berrangé -
Demi Marie Obenour -
Fabio Alessandro Locati -
Gary Buhrmaster -
Kevin Kofler -
Lukas Javorsky -
Zbigniew Jędrzejewski-Szmek