Change 'microdnf update' call to not install weak dependencies of rpms

[soenkeliebau]

Description

The investigation into this was caused by some images suddenly containing openssl binaries despite us having actively removed that dependency earlier.

This was caused by a 'suggests' dependency on the openssl-libs rpm package on openssl-pkcs11, which in turn has a dependency on openssl itself.

Up until now this was not an issue, as this only is triggered when openssl-libs is installed by microdnf update, which so far never happened, as the ubi8 image always contained the latest version.

What I would highly prefer to this solution is to remove all calls to 'microdnf update' from all our images. As proven by this episode, it makes image builds totally non-deterministic as they depend on which packages are available in the rpm repo.

Definition of Done Checklist

• 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
- [ ] Things not downloaded from Red Hat repositories should be mirrored in the Stackable repository and downloaded from there
- [ ] All packages should have (if available) signatures/hashes verified
- [ ] Does your change affect an SBOM? Make sure to update all SBOMs

[lfrancke]

You'll hate me for it but can you please add a comment as to why we add that command. Possibly just a reference to this issue could be enough.

[soenkeliebau]

"Happy" to in principle, but before I do that, I'd like to discuss if this is what we want, or if we can maybe just

• get rid of the update call alltogether
• replace it with something more limited that satisfies best practice like RUN dnf -y update-minimal --security --sec-severity=Important --sec-severity=Critical as suggested by best practice 5 on this page

[lfrancke]

I have reached out to RedHat and now need to create a ticket upstream to ask for opinions so I'd like to hold this for a while longer.

[soenkeliebau]

works for me.
We just need to be aware that openssl is in all our images again until we do something about this - doesn't mean anything I guess, but that is what triggered this.

[soenkeliebau]

I compared our kafka images, built with weak dependencies and without weak dependencies, just to get an idea of the difference that makes.

Weak deps enabled
✔ Cataloged packages [417 packages]
✔ Scanned image [327 vulnerabilities]
Critical: 7
High: 29
Medium: 136
Low: 139

Weak deps disabled
✔ Cataloged packages [371 packages]
✔ Scanned image [240 vulnerabilities]
Critical: 7
High: 28
Medium: 85
Low: 104

[soenkeliebau]

We got the following response from RedHat:

Hello,

My name is Carroline and I am from the Containers Team.

On checking the problem description I see that :

1. A plan to build a product based on the UBI 8 images by following the documentation : Adding software to a UBI container

2. The issue is that : one should run "microdnf update" but that this installs weak dependencies by default which is not expected

3. Now , as per the document :

   • On UBI init and UBI standard images, use the dnf command
   • On UBI minimal images, use the microdnf command

4. Microdnf will be used only when we use ubi8-minimal

5. Also, we have an option to diable the weak dependencies via --setopt install_weak_deps=false

# dnf install \
    --installroot $micromount \
    --releasever=/ \
    --setopt install_weak_deps=false \
    --setopt=reposdir=/etc/yum.repos.d/ \
    --nodocs -y \
    httpd
# dnf clean all \
    --installroot $micromount

6. Also , for permanent disable you can set install_weak_deps=False in /etc/dnf/dnf.conf file.

7. Just a note : Notable RPM features and changes

Do let me know if there are further queries.

This doesn't provide any new insights or details.

@lfrancke
I suggest that we merge this and wait to see if integration tests still pass. I fixed any breakages where we were missing dependencies after the change I hope.

In parellel we can continue the discussion with RedHat to see if we can gain any additional insight there. If we do make the change, I'd rather make it now and give us some time before the release to find any knock-on effects though.