Hello,

I initially installed postgresql-11.2 on centos 7 server using yum.
After that, I compiled php 7.3.4 on centos 7 server with the following commands:
a) ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
--with-bz2 \
--with-zlib \
--with-openssl=/usr/local/openssl \
--with-curl \
--with-freetype-dir=/usr/local/include/freetype2/freetype \
--with-gd \
--enable-mbstring \
--with-mysqli \
--enable-ftp \
--with-pgsql \
--with-pdo-pgsql=/usr/pgsql-11/bin \
--enable-soap \
--enable-bcmath

b) make clean
c) make
d) make test
e) make install

I got the following errors while doing c):
1) /usr/bin/ld: warning: libssl.so.10, needed by /usr/pgsql-11/lib/libpq.so, may conflict with libssl.so.1.1
2) /usr/bin/ld: warning: libcrypto.so.10, needed by /usr/pgsql-11/lib/libpq.so, may conflict with libcrypto.so.1.1

How do I solve this problem?

Best Regards
Thayalan

The php available for RHEL7/CentOS7 from default repositories is php 5.4.16-46.el7.

Why do you think you need php 7.3.4 rather than that version?

On our RHEL7 Postgres 11.x server we don't even have php installed at all.

You have to understand that RHEL/CentOS is designed as a collection of software that has been vetted to work together. When installing other packages you need to consider what they require. Ultimately dependencies could force you to change the underlying openssl or libc at which point it isn't really RHEL7/CentOS7 any longer. Rather than going down that path you'd be better off going down a path that allows you to use the latest of everything such as the latest Fedora. The downside of that is you have to upgrade at least once a year to a new major release of Fedora. With RHEL/CentOS on the other hand you can update packages without doing a major release (i.e. to RHEL8/CentOS8) for several years. It is a question of stability vs bleeding edge. RHEL/CentOS are designed for Production use whereas Fedora and similar distros recommend you not use it for Production.

Hello Mensa Water,

I wanted to use the latest stable available packages for production.
I initially had openssl 1.0.2k. I then installed the latest stable openssl 1.1.1b. I can't change the initial openssl version 1.0.2k completely because it is used by yum and some other system packages. Therefore, now some packages use openssl 1.0.2k whereas others use openssl 1.1.1b from location, /usr/local/openssl.

But, I guess that the errors:
1) /usr/bin/ld: warning: libssl.so.10, needed by /usr/pgsql-11/lib/libpq.so, may conflict with libssl.so.1.1
2) /usr/bin/ld: warning: libcrypto.so.10, needed by /usr/pgsql-11/lib/libpq.so, may conflict with libcrypto.so.1.1

are quite common. If so, in general what should i do? I tried the following:
i) ln -s /usr/local/openssl/bin/libssl.so.1.1 /usr/lib64/libssl.so.1.1
ii) ln -s /usr/local/openssl/bin/libssl.crypto.1.1 /usr/lib64/libcrypto.so.1.1

but to no avail. Therefore do you have any suggestions as to how I should proceed?

Not really. As I mentioned openssl and libc are two very basic packages in any install and trying to use anything other than the ones provided by the RHEL/CentOS distros leads you into dependency hell. You'd end up need to essentially create most packages in /usr/local to support the openssl you installed there.

I went down that rabbit hole on RHEL5 because I wanted a curl version that supported TLS v1.1 or higher (the repository provided one only did TLS 1.0). The amount of effort it took just to get all the packages to allow that upstream version of curl to install was incredible. Even though I got the new upstream curl installed it immediately failed because the underlying openssl didn't support the higher TLS versions. I gave up at that point because of the conversation I'd had with RedHat support as to why they didn't offer a newer upstream openssl.

If you really feel you must use the latest upstream openssl and other packages you need to move to a different distro like Fedora that allows for it.

To get PCI (Payment Card Industry) certified (a security certification), I do need to get the latest packages installed mostly w.r.t openssh, apache and php. This means that these packages need to get the latest version of openssl involved. That is why, I am doing these things as mentioned earlier. Does anyone have any ideas as to how I should tackle the issue mentioned in the first thread?

I also agree with MensaWater that you should use your distro's official packages, in order to receive the necessary updates.
If you're sure you want the latest php, you can get it from a third party repository.

Regards

2 members found this post helpful.

No they don't. We're PCI compliant and do not use the latest upstream. We simply answer the scans showing the patched versions of RHEL provided packages address any specific CVE they list. There is one item we've been answering for several years because they always say Apache 2.2 is vulnerable. The specific CVE they list is from 2011.

Scanners used to determine compliance and security including those by PCI auditing companies are brain dead. They determine only the base upstream version you are using and ignore extended versioning. The RHEL model is to always use the same upstream version of a package through the life of the major RHEL release. They then backport bug and security fixes from later upstream versions into their base version and change the extended version. For the Apache 2.2 CVE they list we verified long ago the extended RHEL version we have was patched so is not vulnerable.

You can also save yourself a lot of grief by simply disabling reporting of the exact version of packages you are using like php. Since the scanners are brain dead they pass you simply because they can't determine the version.

1 members found this post helpful.

Hello bathory and MensaWater,

Your answers were helpful.
Thank you very much!

1 members found this post helpful.