[MIR] pcre2

Bug #1636666 reported by Jeremy Bicha on 2016-10-26
60
This bug affects 8 people
Affects Status Importance Assigned to Milestone
pcre2 (Ubuntu)
Undecided
Unassigned

Bug Description

Availability
============
Synced with Debian. Built for all supported architectures.

Rationale
=========
Required by vte2.91 0.46+ and gnome-terminal 3.22+.
The Ubuntu Desktop team has postponed the need for this transition by reverting the vte and gnome-terminal commits that switched to pcre2.

Security
========
At least one open security issue, affecting Ubuntu 16.04 LTS
https://people.canonical.com/~ubuntu-security/cve/pkg/pcre2.html
https://security-tracker.debian.org/tracker/source-package/pcre2
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pcre

Quality assurance
=================
- Please subscribe Ubuntu Desktop Bugs or Ubuntu Foundation Bugs (like pcre3) to this package.
https://bugs.launchpad.net/ubuntu/+source/pcre2
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pcre2

Upstream tests are run during the build but there is no autopkgtest

Does not have 3.0 (quilt) set

Dependencies
============
Only build-dependencies are dpkg and debhelper. No other added dependencies.

Standards compliance
====================
3.9.6

Maintenance
===========
- Actively developed upstream
http://pcre.org/

Background information
======================
As the package description states, the older version of this library is confusingly named pcre3 in Debian/Ubuntu. pcre3 is already in Ubuntu main.

Transition
==========
https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html

https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2.html

Other Info
==========
In the original release of pcre2 in Jan 2015, the author says this is not just a drastic update to the original pcre but a "new project". He felt free to change names and options.
https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html

pcre3 has gotten some bugfix releases since then (from 8.36 to 8.40 released Jan 2017)

Some discussion of how it's different:
http://www.regular-expressions.info/pcre2.html

PCRE3 Reverse Dependencies in Main
==================================
http://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html (manually compiled list)

Can be built with pcre2:
- clamav <https://github.com/vrtadmin/clamav-devel/commit/85131d40f2990010>
- git [bug 1729075]
- haproxy <https://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=f2592b29f13907dd>
- libselinux <https://github.com/SELinuxProject/selinux/commit/50f0910cf05bdc1d1>
- wget

Can NOT be built with pcre2:
- apache2 <https://bz.apache.org/bugzilla/show_bug.cgi?id=57471>
- exim4 <https://bugs.exim.org/show_bug.cgi?id=1878>
- freeradius
- glib2.0 https://bugzilla.gnome.org/755693
- libpam-mount
- nginx (blocked on exim4?)
- nmap
- php7.2 (but php7.3 will switch to pcre2)
- postfix
- python-pyscss
- rasqal
- sssd

Jeremy Bicha (jbicha) on 2016-10-26
description: updated
Michael Terry (mterry) on 2016-10-31
Changed in pcre2 (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Matthias Klose (doko) wrote :

> pcre3 is already in Ubuntu main

we don't want to have two versions in main. please could you evaluate first what is needed to demote pcre3?

Changed in pcre2 (Ubuntu):
status: New → Incomplete
Jeremy Bicha (jbicha) wrote :

If y'all are indeed going to block on there not being allowed to have 2 pcre's in main, then I guess we'll either have to figure out how to hack vte2.91 and gnome-terminal to either not use pcre2 or instead use the older pcre3. Or we'll just keep using the current gnome-terminal/vte.

$ reverse-depends -c main src:pcre3

Changed in pcre2 (Ubuntu):
milestone: none → ubuntu-17.03
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in vte2.91 (Ubuntu):
status: New → Confirmed
Jeremy Bicha (jbicha) wrote :

For zesty, I have proposed reverting the mandatory pcre2 changes so that we can do the vte/gnome-terminal update. See bug 1666264

Like I wrote there, I am concerned about how long these reverts can be maintained with new versions.

Jeremy Bicha (jbicha) wrote :

I added an Other Info section.

description: updated

I understand the concerns, and I share them, but I don't think we should alone make the decision. Perhaps bring this up for wider discussion on the ubuntu-devel mailing list?

To be clear, I share doko's feeling against having two versions of the library in main if it can be avoided -- this is certainly not a permanent situation, but most things don't appear to have switched to pcre2 just yet (and I would expect they would in the near-ish term). In that sense, I'd be more in favor of not upgrading vte/gnome-terminal for the time being.

To make it simpler: how do we value the benefits of a new pcre2 in main (meaning possibly some new features of gnome-terminal and vte) against the (probably small, but still) maintenance burden of having two PCRE libraries in main or the need to hold gnome-terminal and vte back for this cycle?

To me wearing the MIR team hat, the benefits don't outweigh the increased maintenance work (ie. you can do nothing to vte and gnome-terminal, and we're good), especially when you consider that pcre is the kind of thing that does tend to have CVEs every once in a while[1].

On the other hand, new features are shiny, but they look to me like they might be cherry-pickable. I'm open to be convinced, and the security team probably should have a say in it too (hence my suggestion of bringing it up on the mailing list).

[1] http://www.cvedetails.com/product/5715/Pcre-Pcre.html?vendor_id=3265

Changed in pcre2 (Ubuntu):
milestone: ubuntu-17.03 → ubuntu-17.05
willmo (willmo) wrote :

It seems likely that Ubuntu will have to support/ship both PCRE and PCRE2 before long. At least some other distros (Fedora, Gentoo, Debian) appear to be doing that already.

As mentioned above, for packaging purposes PCRE2 is effectively a new project, *not* a new version of the previous PCRE. The APIs are completely incompatible, and the previous PCRE is still getting bugfixes and seems to be supported/recommended for existing projects that already use it. There are a number of largish projects that don't support PCRE2 and presumably won't anytime soon (e.g. https://bz.apache.org/bugzilla/show_bug.cgi?id=57471).

So it seems unlikely that the whole package ecosystem will ever simultaneously support a single incarnation of PCRE, allowing Ubuntu to ship only that one. Already some packages don't support the old incarnation, and as mentioned above, it's likely that some will never support the new incarnation.

"Other distros do it" isn't sufficient rationale, by itself, to support putting pcre2 in main. We already ship it, the question is whether it should be in main, meaning whether Canonical will be responsible for support, providing security updates, etc.

To mirror what doko mentioned earlier, what is needed to demote pcre3? Can we start (even a long-running) transition? (So there should be a tracker setup for that).

There seems to be new security issues too.

I don't have a preference on what version of pcre to use, there should just be a reasonable analysis of how far we are to being able to just one pcre, what the steps needed to get there, possibly bugs open or a transition tracker to follow progress, and whether we can more easily port what seems to require pcre2 now back to pcre3 in order to facilitate maintenance. Should we / can we invest time and effort in porting things from pcre3 to pcre2?

Jeremy Bicha (jbicha) on 2017-05-03
no longer affects: vte2.91 (Ubuntu)
no longer affects: gnome-terminal (Ubuntu)
description: updated
description: updated

Updating milestone to denote I'm still tracking this.

Changed in pcre2 (Ubuntu):
milestone: ubuntu-17.05 → ubuntu-17.06

Seems like this is coming up again now by way of git.

Changed in pcre2 (Ubuntu):
milestone: ubuntu-17.06 → ubuntu-17.08
Naftoli Gugenheim (naftoligug) wrote :

What is the rationale for not wanting to have both packages in Ubuntu?

As stated, despite the name it is not considered an update but a separate project.

Jonathan Nieder (jrnieder) wrote :

On the subject of the relationship between pcre3 (the older one) and pcre2 (the newer one):

$ eu-readelf -s.dynsym /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 |grep -v UNDEF >/tmp/libpcre2-8.so.0.dynsym
$ eu-readelf -s.dynsym /lib/x86_64-linux-gnu/libpcre.so.3 |grep -v UNDEF >/tmp/libpcre.so.3.dynsym

They export disjoint sets of symbols.

Jonathan Nieder (jrnieder) wrote :
Jonathan Nieder (jrnieder) wrote :

> To mirror what doko mentioned earlier, what is needed to demote pcre3? Can we start (even a long running) transition? (So there should be a tracker setup for that).

Sounds good to me. What's the process for making that happen?

Keep in mind that since pcre2 is a new API and ABI, packages will not migrate to it automatically. But upstreams are likely to update over time.

Jeremy Bicha (jbicha) wrote :

Jonathan, thanks for your input.

I did set up trackers. Except for 'git', I don't think we've made much progress on converting packages at all.

https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2.html
https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html

There is one other issue: Debian's pcre2 isn't really using what I consider "best practice" packaging [specifically, it does not use source format 3.0 (quilt) ] which makes doing security updates more of a pain and is my excuse for having not fixed the outstanding pcre2 security issues in stable Ubuntu releases.

Jonathan Nieder (jrnieder) wrote :

> There is one other issue: Debian's pcre2 isn't really using what I consider "best practice" packaging [specifically, it does not use source format 3.0 (quilt) ] which makes doing security updates more of a pain

That's tracked at https://bugs.debian.org/862425 (thanks for filing it!). I can look into preparing a patch for it if I get time, though no promises.

Jeremy Bicha (jbicha) wrote :

If you do work on that, the hidden Vcs is browseable at
https://browse.dgit.debian.org/pcre2.git/

so convert the git commits to regular patches.

Anders Kaseorg (andersk) wrote :

I did some quick searches to assess the state of upstream PCRE2 support in the packages listed on Jeremy’s tracker. It’s better than I thought:

• ClamAV, Git, HAProxy, SELinux, PHP, Qt, and VTE upstream all support PCRE2.
• PHP, Qt, and VTE upstream all _require_ PCRE2 now.
• In fact, Qt in Ubuntu 17.10 main is _already using_ (a bundled copy of) PCRE2! Go look at the build log.

https://github.com/vrtadmin/clamav-devel/commit/85131d40f29900109798b1af4a71d79e8ff996a9
https://bugs.launchpad.net/ubuntu/+source/git/+bug/1729075
https://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=f2592b29f13907ddf2bba42d00bc41cb8ee5b69b
https://github.com/SELinuxProject/selinux/commit/50f0910cf05bdc1d10710c7c3fb748a178473387
https://github.com/php/php-src/pull/2857
https://github.com/qt/qtbase/commit/9ff34b3a088867d66daa782a4d5dbed99cd8ede4
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1666264

So it seems unlikely that sticking our head in the sand will keep PCRE2 out of main for very long even if we wanted that.

Matthias Klose (doko) wrote :

> I did some quick searches to assess the state of upstream PCRE2
> support in the packages listed on Jeremy’s tracker.

thanks for pointing that out. I didn't check myself, but how many of these packages are already using pcre2 in Debian?

> So it seems unlikely that sticking our head in the sand will
> keep PCRE2 out of main for very long even if we wanted that.

I don't think that this is an accurate description. Your trackers are a step forward, however a PPA with using pcre2 would give more confidence that we don't get stuck in the middle of a transition.

Also the package seems to be behind 18 months behind with releases compared to upstream, and we don't have the packaging issue resolved yet in https://bugs.debian.org/862425. All this doesn't sound very promising to only have to maintain one pcre version in 18.04. Please can we start with a PPA to see if we can accomplish this transition in time for bionic?

Dmitry Shachnev (mitya57) wrote :

> • In fact, Qt in Ubuntu 17.10 main is _already using_ (a bundled copy of) PCRE2! Go look at the build log.

We just merged a Qt upload from Debian where it was unbundled, and now qtbase is uninstallable because pcre2 is in universe.

Of course we can switch back to the bundled version, but I don’t see how this can be better than just approving this MIR. Any progress on this, now that the transition tracker exists?

Changed in pcre2 (Ubuntu):
status: Incomplete → New
description: updated
description: updated
Jeremy Bicha (jbicha) on 2018-02-05
description: updated

Let's get the security team's opinion on maintaining this for its security aspect. I will leave it to Steve to weigh in on Foundations maintaining the package, since the Foundations team currently maintains pcre3.

Changed in pcre2 (Ubuntu):
assignee: Mathieu Trudel-Lapierre (cyphermox) → Ubuntu Security Team (ubuntu-security)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pcre2 (Ubuntu):
status: New → Confirmed
Matthias Klose (doko) wrote :

afaics, the comments in #21 are still valid. There is no analysis yet what needs converting to this new version.

Changed in pcre2 (Ubuntu):
status: Confirmed → Incomplete
Changed in pcre2 (Ubuntu):
milestone: ubuntu-17.08 → none
Jamie Strandboge (jdstrand) wrote :

Speaking for the security team, it seems there is no consensus on if pcre2 should be in main and therefore require a security review. I tend to agree with foundations that we should not support pcre and pcre2 if we can avoid it, however packages that are in main that simply bundle it is not avoiding the problem-- it is only hiding the fact that it is actually supported via an embedded code copy, which is against standard practice.

For the moment I am unsubscribing the security team, but considering my comments on embedded copies, feel free to resubscribe if its inclusion will be reconsidered.

Changed in pcre2 (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Matthias Klose (doko) wrote :

#21 and #25 are still valid. No work estimates yet.

Jeremy Bicha (jbicha) wrote :

vte2.91 and gnome-terminal dropped support for the old pcre 2 years ago. So that we wouldn't be stuck on old versions of these essential desktop components indefinitely, I hacked vte2.91 and gnome-terminal to keep the old code.

The developers of at least tilix, gnome-builder, and xfce4-terminal are annoyed by Ubuntu's vte2.91 package that does not support pcre2. Tilix and GNOME Builder have features that do not work on Ubuntu because of this. The Tilix developers are really annoyed because they are continually getting bug reports from people who try to compile Tilix on Ubuntu which will not work without Ubuntu-specific hacked patches.

I think it was acceptable to do this for Ubuntu 18.04 LTS, but we can't keep our forked packages here forever.

It is completely impractical to require that all of main switch to pcre2 before any of main is allowed to switch. main will need to use the old pcre, probably for years to come. This should not be a blocker in this case.

I now am beginning to regret that I hacked vte2.91 and gnome-terminal. If I hadn't, maybe we would have been more convincing to Foundations and Security that this situation cannot continue.

Matthias Klose (doko) wrote :

> It is completely impractical to require that all of main switch to pcre2
> before any of main is allowed to switch. main will need to use the old
> pcre, probably for years to come. This should not be a blocker in this
> case.

that is not what was asked for. The required information was a way forward, what things work out of the box, and which packages need porting work. And yes, I consider this as a blocker, until this work is done. Why is this so difficult to procide this information?

Jeremy Bicha (jbicha) wrote :

Sorry, I wasn't entirely clear what information you're asking for.

So a simple reverse-depends -r sid -b src:pcre2 (or leave out the -b) shows that Debian's clamav, get, php7.3, qtbase-opensource-src, and vte2.91 packages are using pcre2 now.

I don't like pcre's packaging workflow in Debian with source format 1.0 but I don't know whether Security wants to diverge for that.

Debian's pcre2 package is almost up-to-date. There was a new release a few days ago not in Debian yet.
https://pcre.org/news.txt

Do you have any other specific questions?

Matthias Klose (doko) wrote :

no, this would be backwards. The goal should be the demotion of pcre3. These are the reverse depends of pcre3 in main:

aide
apache2
apr-util
clamav
exim4
freeradius
git
glib2.0
grep
haproxy
libpam-mount
libselinux
nginx
nmap
php7.2
postfix
python-pyscss
quagga
rasqal
slang2
sssd
wget
zsh

What we need is an analysis which packages already can be built with pcre2, and which ones require some porting work. I opened now LP: #1792544 to track this analysis.

Anders Kaseorg (andersk) wrote :

The requested analysis, relevant or not, has now been provided on bug 1792544.

Changed in pcre2 (Ubuntu):
status: Incomplete → Confirmed
Jamie Strandboge (jdstrand) wrote :

It is clear that we cannot drop pcre3 any time soon due to the number of supported packages that only support it and not pcre2. pcre3 has a *significant* CVE history (52 since 2005 with the latest in 2017 - granted many of those were the result of fuzzing, but the nature of pcre means it will often be fed untrusted input). Furthermore, our goals for main are clear: https://wiki.ubuntu.com/MIRTeam#Duplication. With pcre3 and pcre2 as alternative APIs for working with Perl Compatible Regular Expressions, that is clear duplication. pcre2 comes from the pcre3 codebase and there is no reason to think it won't have a similar number of CVEs-- indeed, pcre2 already has had 26 CVEs assigned to it so far. IMHO, it was premature for vte and gnome-terminal to drop support for the old APIs (even glib2.0 is using pcre3).

-1 for having both implementations in main at this time. In terms of effort, it's clear (to me) that today the least effort overall is continuing to adjust vte/gnome-terminal so we don't have to migrate a bunch of other packages. From a security POV, it seems one is not preferable to the other in terms of raw CVEs since at least for the time being upstream is committed to bug fixes for the old APIs[1]. I suspect pcre2 is going to be better supported by its upstream over time so adding support for pcre2 to the packages we care about is probably a good thing. I wonder if instead of patching pcre2 out of vte, we patch back in support for pcre3 and allow people to choose which they prefer at compile time. This would hopefully be upstreamable.

[1]https://www.pcre.org/ - "The older, but still widely deployed PCRE library, originally released in 1997, is at version 8.42. Its API and feature set are stable-- future releases will be for bugfixes only. Any new features will be added to PCRE2, and not to the PCRE 8.x series."

Anders Kaseorg (andersk) wrote :

And is this going to mean keeping php7.3 out of main?

Marius Gedminas (mgedmin) wrote :

Apparently journalctl --grep requires pcre2 too (bug 1751006).

Nish Aravamudan (nacc) wrote :

@andersk: 7.3.0~beta2-2 of php7.3 dropped pcre3 as a dependency and reverted back to pcre2.

Anders Kaseorg (andersk) wrote :

@Nish: Remember, that’s neither “revert” nor “back”. pcre3 is misnamed, it’s the old library; pcre2 is the new one. This MIR is for pcre2. What I’m saying is, as long as this MIR is rejected, the new dependency of php7.3 on pcre2 will keep it out of main.

Nish Aravamudan (nacc) wrote :

@andersk: you are totally correct, I apologize!

Jamie Strandboge (jdstrand) wrote :

With php7.3's new dependence on pcre2, it is infeasible to back out the pcre2 patches in php in favor of pcre3 like we do for gnome-terminal. It is also a shame that packages like libqt5core5a are embedding it (that was a very uncool move btw); we still end up supporting it after all. At this point, I'm removing the NAK for pcre2 in main.

Please note, this is not a security team ACK-- I think the security team should take a look at the code like a regular MIR since it is effectively a new codebase.

Changed in pcre2 (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Jamie Strandboge (jdstrand) wrote :

Assigning ubuntu-security to perform an audit of pcre2.

Anders Kaseorg (andersk) wrote :

(FWIW, Qt5 was embedding pcre1 before they switched to embedding pcre2, so I don’t see anything specifically uncool about that move: it has always been up to the package maintainer to look at embedded dependencies and provide system versions if desired.)

Jamie Strandboge (jdstrand) wrote :

"it has always been up to the package maintainer to look at embedded dependencies and provide system versions if desired"

The *Ubuntu* package maintainer should not do this for officially supported packages without prior approval because it affects the maintenance cost of the package (detailed in https://wiki.ubuntu.com/MIRTeam#Embedded_sources_and_static_linking).

Dmitry Shachnev (mitya57) wrote :

Actually qtbase-opensource-src is now in universe (and uses system pcre2), so I have removed it from the list.

description: updated
Julian Andres Klode (juliank) wrote :

Moved wget to correct list: wget is built with pcre2 now in Debian, I reverted to pcre3, but it would be good to not keep that delta.

description: updated
Seth Arnold (seth-arnold) wrote :

I reviewed pcre2 version 10.32-3 as checked into disco. This shouldn't
be considered a full security audit, but rather a quick gauge of
maintainability.

- pcre2 is a regular expression library

- There are 25 CVEs for pcre2 in our database -- though this may be an
  over-count or under-count, as the pcre2 project has an awkward
  relationship with fuzzer-found issues:

  - The pcre2 team says any memory-unsafety due to using
    PCRE2_NO_UTF_CHECK (possibly other flags) is entirely programmer
    error. This is almost reasonable enough except it's a shame that a
    brand-new RE library has memory safety issues in this day and age.

  - So some of these CVEs may be disputed / rejected / ignored by
    upstream as a "don't do that" issue. And, likewise, because a great
    number of people have reported a great number of memory-safety issues
    to the pcre2 developers, there's a very real chance that actual
    security issues have *not* been assigned CVEs due to general fatigue.

- Build-Depends: debhelper (>=9), dpkg-dev (>= 1.16.1~)
- Does not daemonize
- No pre/post inst/rm
- No init scripts
- No systemd unit files
- No dbus services
- No setuid
- pcre2grep, pcre2-config, pcre2test in PATH
- No sudo fragments
- No udev rules
- Decent sized test suite, run during the build, that will be helpful

- Subprocesses can be spawned via pcre2grep -- this MUST be disabled in
  our packaging
- Memory management is extremely intricate and involved
- The JIT uses O_TMPFILE files, pcre2grep will automatically ungzip,
  unbz2, or read normal files
- Error logging looked careful
- JIT uses secure_getenv("TMPDIR"), pcre2grep uses some colour and
  locale environment variables
- No privileged operations
- No cryptography
- No privileged portions of code
- Temp file handling looked careful
- No WebKit
- No PolicyKit
- Some cppcheck errors -- some false positives. The others were fixed very
  shortly after I filed a bug: https://bugs.exim.org/show_bug.cgi?id=2355

Please disable SUPPORT_PCRE2GREP_CALLOUT in our builds. Absolutely no
one will expect a tool named 'grep' to execute commands as part of what
it does. (The execution itself looks fine; it is the fact that it *does*
execute that is extremely surprising.)

pcre2 is extremely dense code. Maintenance will require upstream's
assistance for nearly every issue. Operations as common and expensive
as regular expression matching may justify the code complexity but the
large number of memory-safety issues is a strong concern.

However enough applications have converted to pcre2 that I'm not sure we
can realistically hold off supporting pcre2 any longer. The maintenance
costs to keep all supported packages using older pcre will eventually
outweigh the costs to maintain pcre2, so we might as well adapt.

Security team ACK to promote pcre2 to main CONDITIONAL upon disabling
SUPPORT_PCRE2GREP_CALLOUT in our packages.

Thanks

Changed in pcre2 (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Jeremy Bicha (jbicha) wrote :

I have disabled SUPPORT_PCRE2GREP_CALLOUT in
https://launchpad.net/ubuntu/+source/pcre2/10.32-3ubuntu1

The build log now reads:
Enable callouts in pcre2grep ....... : no

Laurent Bigonville (bigon) wrote :

FTR I'm planning to switch selinux in debian to pcre2 after buster release

Matthias Klose (doko) wrote :
Download full text (4.1 KiB)

Override component to main
pcre2 10.32-3ubuntu1 in disco: universe/misc -> main
libpcre2-16-0 10.32-3ubuntu1 in disco amd64: universe/libs/optional/100% -> main
libpcre2-16-0 10.32-3ubuntu1 in disco arm64: universe/libs/optional/100% -> main
libpcre2-16-0 10.32-3ubuntu1 in disco armhf: universe/libs/optional/100% -> main
libpcre2-16-0 10.32-3ubuntu1 in disco i386: universe/libs/optional/100% -> main
libpcre2-16-0 10.32-3ubuntu1 in disco ppc64el: universe/libs/optional/100% -> main
libpcre2-16-0 10.32-3ubuntu1 in disco s390x: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco amd64: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco arm64: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco armhf: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco i386: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco ppc64el: universe/libs/optional/100% -> main
libpcre2-32-0 10.32-3ubuntu1 in disco s390x: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco amd64: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco arm64: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco armhf: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco i386: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco ppc64el: universe/libs/optional/100% -> main
libpcre2-8-0 10.32-3ubuntu1 in disco s390x: universe/libs/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco amd64: universe/debian-installer/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco arm64: universe/debian-installer/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco armhf: universe/debian-installer/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco i386: universe/debian-installer/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco ppc64el: universe/debian-installer/optional/100% -> main
libpcre2-8-0-udeb 10.32-3ubuntu1 in disco s390x: universe/debian-installer/optional/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco amd64: universe/debug/extra/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco arm64: universe/debug/extra/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco armhf: universe/debug/extra/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco i386: universe/debug/extra/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco ppc64el: universe/debug/extra/100% -> main
libpcre2-dbg 10.32-3ubuntu1 in disco s390x: universe/debug/extra/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco amd64: universe/libdevel/optional/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco arm64: universe/libdevel/optional/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco armhf: universe/libdevel/optional/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco i386: universe/libdevel/optional/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco ppc64el: universe/libdevel/optional/100% -> main
libpcre2-dev 10.32-3ubuntu1 in disco s390x: universe/libdevel/optional/100% -> main
libpcre2-posix0 10.32-3ubuntu1 in disco amd64: universe/libs/optional/...

Read more...

Changed in pcre2 (Ubuntu):
status: Confirmed → Fix Released
Jeremy Bicha (jbicha) wrote :

We are using https://launchpad.net/bugs/1792544 currently to track Ubuntu main packages using pcre3.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.