PCRE2 is a build requirements. The build will automatically decide whether to use the system PCRE2 or try to download one.
You can also force the desired outcome with -DWITH_PCRE=system or -DWITH_PCRE=bundled.

Note that on our debian builders nothing is downloaded, see e.g. https://buildbot.askmonty.org/buildbot/builders/kvm-deb-stretch-amd64/builds/12728/steps/compile/logs/stdio

But it looks like dependencies aren't correctly specified in the control file, it should require libpcre2-dev, not libpcre3-dev.

And the build isn't easy to backdoor, because cmake verifies the md5 hash of the downloaded tarball. So an attacker would need to create a poisoned tarball with exactly the same md5 hash to be able to compromise the build.

I see what you are doing in https://github.com/MariaDB/server/commit/e1301160097a25e62fd1c660bb69ada61bac7e39

However, libpcre3-dev (>= 2:8.35-3.2~) is actually available in all Debian and Ubuntu since long (https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=libpcre3-dev). The d/control file line was inherited from https://github.com/MariaDB/server/commit/7f570bef1e3a6b19925bf7e58e02b975548039eb and the same has been in Debian official packaging for years: https://salsa.debian.org/mariadb-team/mariadb-10.4/-/blob/master/debian/control#L25

Are you sure downgrading to libpcre2 is the correct solution?

serg I am happy to review/test if you make a PR about your fix.

It's not downgrading, it's upgrading. Some weird Debian oddity. For whatever historical reasons old pcre got called libpcre3 in Debian. It is very old and in a slow maintenance mode, not many bugs are getting fixed there. The current active pcre version is pcre2. Which is called libpcre2 in Debian.

Right. That seems to be available from Debian Stretch and Ubuntu Xenial onwards. If we still want working packages for older distro releases than that, the autobake-deb.sh needs some adaptations. At least on buildbot we still have Jessie building:

Do you want me to finalize this change now when I know what needs to be done?

https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=libpcre2-dev
https://packages.ubuntu.com/search?suite=all&section=all&arch=any&keywords=libpcre2-dev&searchon=names

I think we can safely skip Jessie. Its support ends in June 2020, and 10.5 might not even be GA by that time.
Do you think there's anything else to be done besides that one-liner change:

-               libpcre3-dev (>= 2:8.35-3.2~),

+               libpcre2-dev,

?

There is a bit more. I will have this fixed tomorrow once all CI has passed etc: https://github.com/ottok/mariadb/commit/02938af652baea22d3f1c261e0420e851512f74c

Seems there are regressions on both buildbot.askmonty.org and Travis-CI I need to fix before I can put this in... I really hope one day there is a policy that nothing can be merged on a master branch unless all tests are green..

Jessie is now failing with:

-- Looking for pcre2_match_8 in pcre2-8

-- Looking for pcre2_match_8 in pcre2-8 - not found

CMake Error at cmake/pcre.cmake:62 (MESSAGE):

  system pcre2-8 library is not found or unusable

Call Stack (most recent call first):

  CMakeLists.txt:381 (CHECK_PCRE)

-- Configuring incomplete, errors occurred!

See also "/home/buildbot/buildbot/build/mariadb-10.5.2/builddir/CMakeFiles/CMakeOutput.log".

See also "/home/buildbot/buildbot/build/mariadb-10.5.2/builddir/CMakeFiles/CMakeError.log".

debian/rules:68: recipe for target 'override_dh_auto_configure' failed

make[1]: *** [override_dh_auto_configure] Error 1

make[1]: Leaving directory '/home/buildbot/buildbot/build/mariadb-10.5.2'

debian/rules:177: recipe for target 'build' failed

make: *** [build] Error 2

dpkg-buildpackage: error: debian/rules build gave error exit status 2

These failures happen even when the old libpcre3-dev is around.

But as stated, maybe we can ignore that.