F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Ben Cotton]

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(a)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/[e-mail].o...
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
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Kevin Kofler]

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(a)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

[Gary Buhrmaster]

On Wed, Aug 24, 2022 at 3:14 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; 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!

[Daniel P. Berrangé]

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(a)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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Kevin Kofler]

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

[Fabio Alessandro Locati]

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.
-- 
Fabio Alessandro "Fale" Locati
fale.io

[Demi Marie Obenour]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Zbigniew Jędrzejewski-Szmek]

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(a)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

[Lukas Javorsky]

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(a)in.waw.pl&gt; 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(a)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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat <https://www.redhat.com>

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavorsk(a)redhat.com
<https://www.redhat.com>

[Kevin Kofler]

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

[Daniel P. Berrangé]

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(a)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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|