Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSslEnginesCheck: New actor for OpenSSL engines (9->10) #1338

Merged
merged 4 commits into from
Feb 10, 2025

Conversation

Jakuje
Copy link
Contributor

@Jakuje Jakuje commented Feb 4, 2025

The OpenSSL engines are deprecated in OpenSSL 3.0 (RHEL9) and in RHEL10 we removed existing pkcs11 engine and do not support building new engines. This check builds on top of existing 8to9 check OpenSslConfigCheck that I wrote years back that was doing some incompatibilities checks when updating from openssl 1 to 3.

Now, we really do not want users to upgrade with existing engines configured, and especially not with the ones that we removed from distribution (pkcs11), which might break the OpenSSL.

RHEL-78396

Copy link

github-actions bot commented Feb 4, 2025

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

  • review please @oamg/developers to notify leapp developers of the review request
  • /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build.
However, here are additional useful commands for packit:

  • /packit test to re-run manually the default tests
  • /packit retest-failed to re-run failed tests manually
  • /packit test oamg/leapp#42 to run tests with leapp builds for the leapp PR#42 (default is latest upstream - main - build)

Note that first time contributors cannot run tests automatically - they need to be started by a reviewer.

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

  • /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
  • /packit test --labels beaker-minimal-8.10to9.4,kernel-rt-8.10to9.4 to schedule kernel-rt and beaker-minimal test sets for 8.10->9.4 upgrade path

See other labels for particular jobs defined in the .packit.yaml file.

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

@Jakuje
Copy link
Contributor Author

Jakuje commented Feb 4, 2025

I see there are some other common openssl actors already in repos/system_upgrade/common/actors/openssl/ so I will probably move the OpenSslConfigScanner in there in the next iteration.

@Jakuje
Copy link
Contributor Author

Jakuje commented Feb 5, 2025

Ugh. Looking at the other actors, there is #1131 which basically always backs up the modified openssl conf and uses the rpm one on the target system, which means that any changes to the OpenSSL configuration files we made with 8->9 upgrade nor this one nor the one proposed from CRYPTO-15581 would have any effect. So should we just kill these actors and let the actor in handle it all?

https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/common/actors/openssl/migrateopensslconf/actor.py

@pirat89 ?

@Jakuje
Copy link
Contributor Author

Jakuje commented Feb 6, 2025

Sounds like this actor checking the configured engines should be still usable. Even though we will get the new configuration automatically, warning the user if they have the engines hardcoded is still useful information.

Copy link
Member

@pirat89 pirat89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

discussed with @Jakuje , we need better clarification of the impact and remediation instruction regarding pkcs11-engine. Currently we do not know how to properly instruct users about expected impact and actions that should be done.

so should we just kill these actors and let the actor in handle it all?

@neverpanic it makes sense to me still to report this msg, just not sure about <paragraph-above>. maybe it would make a sense to merge few reports together in future but let's keep it split for this release as time is running.

@pirat89 pirat89 added the enhancement New feature or request label Feb 6, 2025
@pirat89 pirat89 added this to the 8.10/9.6 milestone Feb 6, 2025
@Jakuje Jakuje marked this pull request as draft February 7, 2025 09:46
@pirat89 pirat89 marked this pull request as ready for review February 7, 2025 10:06
@pirat89 pirat89 added the changelog-checked The merger/reviewer checked the changelog draft document and updated it when relevant label Feb 10, 2025
The OpenSSL in EL 10 has deprecated engines in favor of providers.

When the user upgrades to EL 10, the openssl configuration file will be
changed to the EL 10 defaults and if the user depends on some engine
for the system to boot or sshd to start, it might break and user needs
to be aware of this.

 * The most common engine we shipped, pkcs11, has been removed from EL 10.
   The pkcs11-provider rpm will be installed automatically based on
   PES data if openssl-pkcs11 has been installed on the source system.
   However, user will be still informed they need to configure the
   system manually after the upgrade to use it.

 * The third-party engines could do anything so user needs to make sure
   neither of them is crucial for the minimal system to work. If they
   are still needed in the target system, they need to be configured
   again, but we recommend finding provider alternatives.

JIRA: RHEL-78396

Signed-off-by: Jakub Jelen <[email protected]>
Copy link
Member

@pirat89 pirat89 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! note that IPU 9 -> 10 is not covered yet by CI. I will do some manual tests after the merge together with other related changes before the release. Usually I would do ti before the merge, but I want to test it with other related stuff at once and it seems that everything is ok regarding the code and component tests. So merging now.

Thank you for the contribution!

@pirat89 pirat89 merged commit 8076b11 into oamg:main Feb 10, 2025
18 of 23 checks passed
@pirat89 pirat89 added the report Any reports have been added / removed / changed in the PR label Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog-checked The merger/reviewer checked the changelog draft document and updated it when relevant enhancement New feature or request report Any reports have been added / removed / changed in the PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants