[razvan]

Description

Fixes: stackabletech/issues#845

Moves stackable-base and stackable-devel to ubi10/ubi-minimal, and makes the Hadoop native code build and work against RHEL 10's OpenSSL 3.5.

What changes

• stackable-base, stackable-devel: ubi10/ubi-minimal@sha256:ab67cd02caf8706e34a695a1432ebe965934f6128ec352a6c3f4048b43a4fb5e, expected certs package ca-certificates-2026.2.92_v9.0.319-100.3.el10_2.

• java-base installs gzip.
  tar -z needs it, and the hadoop final stage unpacks async-profiler with curl | tar -xz.
  On UBI 9 every image built on java-base had gzip, because krb5-workstation pulls in pam, which pulls in cracklib, which requires gzip; on UBI 10 krb5-workstation no longer depends on pam.
  It goes into java-base rather than the hadoop image so that every Java image keeps what it had on UBI 9, and images that never had it do not gain it.
  The installed version is gzip-1.13-4.el10_2, which contains the fixes for CVE-2026-41991 and CVE-2026-41992 (RHSA-2026:61625).

• hadoop 3.4.3 and 3.5.0: three patches for HADOOP-19872:

  • HADOOP-19872: Exclude Engine API when building with OpenSSL 3.x apache/hadoop#8550, which excludes the ENGINE API from OpensslSecureRandom.c when OpenSSL is built without it;
  • a guard of the remaining ENGINE code paths in OpensslSecureRandom;
  • a guard of the ENGINE_by_id and ENGINE_free lookups in OpensslCipher.c, plus the Windows ENGINE_by_free typo.

  The touched files are byte-identical in 3.4.3, 3.5.0 and trunk.
  The two follow-up patches are not part of HADOOP-19872: Exclude Engine API when building with OpenSSL 3.x apache/hadoop#8550.

• hadoop 3.3.6, which hive 3.1.3 and 4.0.0 build against:

  • the first two HADOOP-19872 patches.
    Its OpensslSecureRandom.c is byte-identical to 3.4.3's, and its OpensslCipher.c never looks up an ENGINE, because engine selection arrived in 3.4, so the third patch has nothing to guard;
  • HADOOP-19551 (HADOOP-19551. Fix compilation error of native libraries on newer GCC. apache/hadoop#7644) and HDFS-17226 (HDFS-17226. Building native libraries fails on Fedora 38. apache/hadoop#6191), which 3.4.3 and 3.5.0 already contain.
    GCC 14 makes implicit function declarations an error, which OpensslSecureRandom.c trips over in the pre-1.1 lock helpers, and its headers no longer pull in <cstdint> for libhdfspp.

Why the cipher needs the guard as well

apache/hadoop#8550 alone makes the build pass, but OpensslCipher.initIDs still resolves ENGINE_by_id and ENGINE_free at runtime.
RHEL 10's headers define OPENSSL_NO_ENGINE, yet its libcrypto still exports both symbols, so the lookup succeeds there by accident.
Against a libcrypto without them, initIDs throws UnsatisfiedLinkError and the AES/CTR codec falls back to JceAesCtrCryptoCodec with only a warning, so encrypted data transfer keeps working and nothing reports that native crypto is gone.
With the guard, libhadoop.so references no ENGINE symbol at all.

Testing

Built with boil build hadoop=3.4.3,3.5.0.

In both images:

• hadoop checknative -a reports openssl: true /lib64/libcrypto.so (openssl-libs 3.5.8).
• strings libhadoop.so shows no ENGINE_ symbol.
• A native AES/CTR round trip through OpensslAesCtrCryptoCodec with OpensslSecureRandom: 1 MiB, ciphertext identical to JCE's AES/CTR/NoPadding, decrypts back to the input.

hadoop 3.3.6 builds and passes the same three checks: openssl: true /lib64/libcrypto.so, no ENGINE_ string, and the AES/CTR round trip matching JCE.
zstd and bzip2 report false in checknative, as they do in the 26.7.0 hadoop image.

hive 3.1.3 builds against the patched 3.3.6, and schematool -dbType derby -initSchema completes in the image.
Its checknative reports openssl: false because the hive image has no libcrypto.so symlink; the UBI 9 hive images behave the same, so this is not new.

On a k3d cluster with the 26.7.0 operators, the HDFS kerberos test (both realms, ZooKeeper 3.9.5, OPA 1.16.2, dfs.encrypt.data.transfer with AES/CTR) passes for 3.4.3 and 3.5.0.
Its datanodes log OpensslAesCtrCryptoCodec, which they do not when the codec falls back to JCE.

Known UBI 10 differences

• gzip, see above.
• tput is not installed, so the hadoop scripts print tput: command not found in places. Cosmetic.
• Vector keeps the el9 inotify-tools RPM; it installs and inotifywait runs on UBI 10.

Open question

This changes the base of every image, not only Hadoop.
#1349 asks whether UBI 10 images should be built alongside the UBI 9 ones or replace them, and that is not settled.
Only hadoop 3.4.3 and 3.5.0 ran on a cluster; 3.3.6 and hive 3.1.3 were built and checked in the image only.
No image other than hadoop and hive was built or tested on UBI 10.

Definition of Done Checklist

Note

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant.

Please make sure all these things are done and tick the boxes

• Changes are OpenShift compatible
• All added packages (via microdnf or otherwise) have a comment on why they are added
• Add an entry to the CHANGELOG.md file
• Integration tests ran successfully

TIP: Running integration tests with a new product image

The image can be built and uploaded to the kind cluster with the following commands:

boil build <IMAGE> --image-version <RELEASE_VERSION> --strip-architecture --load
kind load docker-image <MANIFEST_URI> --name=<name-of-your-test-cluster>

See the output of boil to retrieve the image manifest URI for <MANIFEST_URI>.