difficulties with redhat 7 to get php >= 7.0 + openssl >= 1.0.2
Dear all,
i have some beginner questions about redhat specificities.
I have well read the article
but i'm not satisfied with the answer:
- the check each details process is time costly
- the apache signature is important for me and i dont want to hack it
I have also well read the documentation
"If the desired changes cannot be achieved that way, build a new container on top of the provided container image. Write a custom Dockerfile and use the original container in the FROM clause."
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3-beta/html/using_red_hat_software_collections_container_images/extending_images
- i dont want that from a beta repository
- the docker process is again an additional time cost
And i have also well seen similar posts in forum, but which are unanswered from more than 2 weeks
"Hi, My auditor asking to upgrade OpenSSL 1.0.2m due to VA and EOL of current version OpenSSL 1.0.1e-fips."
https://access.redhat.com/discussions/2172641
I'm familiar with Debian where all those requirements (ssl >= 1.0.2 and php >= 7.0) are in standard packages from long.
All this make me really afraid about the time cost for using redhat knowing i'm limited to the 2 repository : standard and software collection.
Any "easy fast and clean" way to achieve the same than Debian like working just with packages or some quick addons ?
All tips are welcome, thanks in advance.
Responses
Hello Fabrice,
I'm sure there's a way to do this with both Red Hat and Debian. The choice is yours. That being said, are you attempting to run security controls against some form of application server that presents some form of data through a web browser? Tomcat, or Apache (httpd), or some other third party form of non-Red-Hat software?
Are you attempting to provide a form of SSL that's FIPS based and not non-FIPS? There are non-beta rpms for current supported editions of Red Hat Enterprise Linux Server. Regarding the article from March 2017 at https://www.redhat.com/en/blog/package-versions-why-our-package-versions-are-almost-never-bumped that speaks of the Red Hat practice of something called "backporting".
Backporting... in short, Red Hat has it's own versioning scheme such that Red Hat's version of the open source project (like tomcat, etc) will be different DETAILS HERE https://access.redhat.com/security/updates/backporting.
The discussion you cited lists a bugzilla which at the bottom of the file shows the resolution in 2017 with this errata (updated rpm) https://access.redhat.com/errata/RHBA-2017:1929 to include resolving a FIPS issue.
All of the above I have written being said, I'm not 100% sure if this addresses your issue, so if necessary, please explain the case-use of what you are doing and your overall goal. Is it your goal to have a Red Hat 7.5 server or Red Hat 6.9 (both are currently supported) with some form of a (undetermined) web service that has FIPS control? Are you concerned over the differences of the open source version versus the versions that Red Hat uses (and so Red Hat's versions will generally never match the open source version, but you can determine (often, usually) if a given CVE is addressed in any given rpm).
Red Hat can be configured to mitigate security concerns and people do this often and place systems into production to mitigate risk and satisfy the requirements of those who evaluate the security concerns. This is a rather broad wide-sweeping statement that would encompass a large scope of security concerns both corporate and non-corporate security concerns that other security conscious organizations have.
Let us know.
Regards,
RJ
RHEL 7's php package probably won't be rebased to PHP 7.
RHEL 7 came out with PHP 5.4 so if we just changed version to 7 then we'd probably break a large number of existing PHP 5.4 installs. That's no good.
PHP 7.0 and 7.1 are provided in the Software Collections as you noticed. I discussed these further in detail with someone here: https://access.redhat.com/discussions/3397781. Pay attention to the lifecycle of SCL packages, the supported lifetime is not as long as the regular distro packages.
I don't quite understand your TLS requirements. My understanding is that mod_ssl doesn't do any TLS itself and depends on the system-wide OpenSSL library to provide crypto. RHEL 7 already ships with openssl-1.0.2k-12.el7 so seems your requirement for OpenSSL 1.0.2 is already met? You probably know more than me about webservers, it's not an area I work in much.
I replied to the outstanding question on the other discussion: https://access.redhat.com/discussions/2172641
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
