-
Bug
-
Resolution: Won't Do
-
Blocker
-
None
-
CentOS Stream 10
-
None
-
None
-
None
-
rhel-sst-security-crypto
-
ssg_security
-
None
-
None
-
None
-
None
-
None
-
None
What were you trying to do that didn't work?
There are a significant number of Fedora packages that have a build requirement on openssl-devel-engine. Many of these are potential candidates for EPEL 10. I noticed that while Fedora provides openssl-devel-engine, CentOS 10 does not. EPEL has had to work around similar situations with unshipped devel subpackages before, and has documentation on how to do it.
https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
I took a run at creating an openssl-epel package to provide the openssl-devel-engine subpackage, and then building the nrpe package against that.
https://copr.fedorainfracloud.org/coprs/carlwgeorge/openssl-epel/builds/
What I discovered was that merely providing the missing header files was insufficient. As best I can tell, the engine headers are effectively masked because the CentOS 10 openssl-devel defines the OPENSSL_NO_ENGINE pre-processor define in its headers. I can understand RHEL taking the position of "we're not going to provide these headers because we're not going to build against them and don't endorse anyone else building against them either", but OPENSSL_NO_ENGINE takes it a step further to actively block anyone else from providing and using the headers themselves.
What is the impact of this issue to you?
Here are the Fedora packages that we are forcibly excluding from EPEL 10 with this approach.
- asio
- cpprest
- erlang
- fsverity-utils
- fuse-encfs
- gambas3
- gdal
- grpc
- hitch
- libcoap
- minizip-ng
- myproxy
- nextcloud-client
- nrpe
- ocspd
- openssl-pkcs11
- osslsigncode
- pdns
- pdns-recursor
- poedit
- proxygen
- pypy
- pypy3.9
- pypy3.10
- qbittorrent
- R-openssl
- rb_libtorrent
- root
- s2n-tls
- sbsigntools
- sendmail
- strongswan
- tor
- tpm2-tss-engine
- trafficserver
- trojan
- uboot-tools
- ufdbGuard
- uperf
- websocketpp
- wesnoth
- workflow
- xca
- yadifa
- znc
EPEL is important to many of our customers, and we should avoid artificially restricting what can be shipped there, if at all possible. We also need to consider the unknown number of third party packages outside of Fedora/EPEL that we would also be excluding from RHEL 10 systems.
Please provide the package NVR for which the bug is seen:
openssl-devel-3.2.2-11.el10
How reproducible is this bug?
always
Steps to reproduce
- build a separate openssl-devel-engine to provide engine.h
- build another package (e.g. nrpe) that build requires openssl-devel-engine
Expected results
success build of package that build requires openssl-devel-engine
Actual results
build failures such as:
./nrpe.c:294:9: error: implicit declaration of function ‘ENGINE_load_builtin_engines’ [-Wimplicit-function-declaration]
Additional info
yselkowi@redhat.com implemented a solution in Fedora that we believe would be appropriate for CentOS/RHEL 10 and allow EPEL 10 to ship its own openssl-devel-engine and allow EPEL packages to build against it.
- relates to
-
RHEL-45704 Enforce OPENSSL_NO_ENGINE in RHEL/CentOS
- Release Pending