Author: John W. Baxter Date: To: exim-dev Subject: Re: [exim-dev] PCRE inclusions in Exim
On 6/14/05 8:51 AM, "Philip Hazel" <ph10@???> wrote:
> On Tue, 14 Jun 2005, V. T. Mueller wrote:
>
>>> This means that if there is a security vulnerability found in PCRE I
>>> have 6 packages to update, whereas if everything used (dynamic linking)
>>> the system version there would be one package to update. This is
>>> exactly the problem which caused significant pain to people a couple of
>>> years back when we were chasing all the packages that happened to have
>>> zlib compiled in statically.
>>
>> Depending on circumstances, there are good arguments both for and against the
>> use of [private] shared libraries. Besides, Apache and PHP for example come
>> with their own pcre.
>>
>> So the straightest way to achieve what you're suggesting would be an
>> availability check for an "already-there-not-too-old" library at pcre link
>> time, wouldn't it?
>
> That is too much of an upheaval for a 4.52 release that I want to get
> out soon. I have, today, modified Exim to include the new-format PCRE
> 6.0 file set, but it is getting messier to "cut down" PCRE for Exim
> because of the new features in PCRE. Something will have to be done in
> due course. One, or even both of:
>
> (1) Insist on a system library being installed.
> (2) Use a *standard* private copy of PCRE, not a cut-down version as now.
I just looked at one of our servers, pcre.so is present (in the /usr tree),
but all four instances are there because of various versions and instances
of Python, and in Python-related directories, eg
/usr/lib/python2.3/lib-dynload/pcre.so
This machine has a fairly old Red Hat installation.