Can we narrow down which component needs libssl1.0.0? One of the many outdated/bundled ones?

libssl1.0.0 is OpenSSL 1.0.1 which is EOLed by upstream. There's still a version in Jessie, which could be forward-ported with some adjustments to be co-installable with the regular OpenSSL packages in Buster.

But I think it's worth to investigate whether we can rebuild the Hue package by Cloudera, but it's likely that the outdated packages in their are incompatible with OpenSSL 1.1, but quickly trying won't hurt.

I found https://github.com/cloudera/hue/issues/629 that contain the fix to upgrade the libssl deps. Given the fact that Hue for CDH 5.X will not ever support python 3+ (see T233073) I'd be inclined to try to build a new package or just build for buster the one shipped for CDH 6.x.

libmysqlclient18 seems also in the rdpends list of hue-common.

The bug https://issues.cloudera.org/browse/HUE-7696 seems inactive, but there are some indications about how to fix the problem (very generic ones). We can try to build our own version of the package and see if it works.

@MoritzMuehlenhoff I forgot that some hadoop-etc.. packages are depending from libssl1.0.0 too:

elukey@analytics1031:~/hadoop-2.6.0+cdh5.16.1+2848$ apt-cache rdepends libssl1.0.0
libssl1.0.0
Reverse Depends:
  librhash0
 |proxysql
  impala
  hue-common
  hadoop-mapreduce
  hadoop-0.20-mapreduce
  rhash

I checked the source packages and this is the control's settings for hadoop-mapreduce:

Package: hadoop-mapreduce
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}, adduser, bigtop-utils (>= 0.7), hadoop-yarn (= ${source:Version}), avro-libs, zookeeper, hadoop (= ${source:Version})

This is the list of deps:

elukey@analytics1031:~/hadoop-2.6.0+cdh5.16.1+2848$ apt-cache depends hadoop-mapreduce
hadoop-mapreduce
  Depends: libc6
  Depends: libgcc1
  Depends: libssl1.0.0
  Depends: libstdc++6
  Depends: adduser
  Depends: bigtop-utils
  Depends: hadoop-yarn
  Depends: avro-libs
  Depends: zookeeper
  Depends: hadoop

I guess that libssl1.0.0 is part of either shlibs or misc Depends? I am not familiar about how they are populated, but I guess during build time. Do you think that the list would change if we build the source for Stretch or Buster?

The libssl1.0.0 package that we currently have on Stretch is a dummy one though, so we could think about porting it to Buster anyway and avoid any hassle. Thoughts?

elukey@analytics1031:~/hadoop-2.6.0+cdh5.16.1+2848$ apt-cache show libssl1.0.0
Package: libssl1.0.0
Source: cdh-libssl1.0.0
Version: 1.0.0
Architecture: all
Maintainer: Moritz Muehlenhoff <moritz@wikimedia.org>
Installed-Size: 9
Multi-Arch: foreign
Priority: optional
Section: misc
Filename: pool/thirdparty/cloudera/c/cdh-libssl1.0.0/libssl1.0.0_1.0.0_all.deb
Size: 2134
SHA256: a9f1d98b5d8d81078347149ccdfa68636f79426df23f859cceaa7e602ed506bf
SHA1: 2673f682f92423238fc9e2093bb1dce48ccd55b0
MD5sum: bbeb28022bfe19d9ea37859efaae8eb5
Description: Fake libssl1.0.0 for CDH
 hadoop-mapreduce depends on libssl1.0.0, but that seems entirely
 spurious. It only ships Jar and a shell script.
 This package provides libssl1.0.0 for this.
Description-md5: 23b19a6819fe0d742eef80cdd41a7426

In T214364#5774214, @elukey wrote:

I guess that libssl1.0.0 is part of either shlibs or misc Depends? I am not familiar about how they are populated, but I guess during build time. Do you think that the list would change if we build the source for Stretch or Buster?

Yes, it gets populated by "${shlibs:Depends}" at build time. See e.g. https://manpages.debian.org/buster/debhelper/dh_makeshlibs.1.en.html for some pointers on shlibs.

${misc:Depends} is similar, but adds e.g. dependencies which are needed by debhelper.

If the deb has libssl1.0.0 in it's Depends that means that it got built with the OpenSSL version from Wheezy or Jessie (or a similar Ubuntu release). Confusingly that refers to OpenSSL 1.0.1 as well.

The libssl1.0.0 package that we currently have on Stretch is a dummy one though, so we could think about porting it to Buster anyway and avoid any hassle. Thoughts?

Stretch had OpenSSL 1.0.2 which is still fairly similar to OpenSSL 1.0.1/1.0.0. Buster defaults to OpenSSL 1.1, which dropped a lot of legacy code and refactored a number of interfaces to shield internals (a number of internals which were previously opaque now need to be accessed through APIs), this will probably not work.

So make sure to pull in libssl1.0.2 on Buster in the Puppet manifests. I think rebuilding the dummy deb is fine, theres less potential for regressions as we can't be 100% sure what they used to create the CDH...

And going forward with Bigtop this will no longer be necessary anyway.