Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-58344

allow third parties to build against their own engine.h

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Blocker Blocker
    • None
    • CentOS Stream 10
    • openssl
    • 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

      1. build a separate openssl-devel-engine to provide engine.h
      2. 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.

      https://src.fedoraproject.org/rpms/openssl/pull-request/65

              dbelyavs@redhat.com Dmitry Belyavskiy
              carlwgeorge Carl George
              Dmitry Belyavskiy Dmitry Belyavskiy
              George Pantelakis George Pantelakis
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: