-
Notifications
You must be signed in to change notification settings - Fork 153
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
Conversation
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.
Packit will automatically schedule regression tests for this PR's build and latest upstream leapp 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,
See other labels for particular jobs defined in the 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. |
I see there are some other common openssl actors already in |
repos/system_upgrade/el9toel10/actors/opensslenginescheck/libraries/opensslenginescheck.py
Outdated
Show resolved
Hide resolved
repos/system_upgrade/el9toel10/actors/opensslenginescheck/libraries/opensslenginescheck.py
Outdated
Show resolved
Hide resolved
repos/system_upgrade/el9toel10/actors/opensslenginescheck/libraries/opensslenginescheck.py
Show resolved
Hide resolved
f198f64
to
d3c3b78
Compare
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? @pirat89 ? |
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. |
repos/system_upgrade/el9toel10/actors/opensslenginescheck/libraries/opensslenginescheck.py
Show resolved
Hide resolved
There was a problem hiding this 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.
c6e9940
to
2b4da9d
Compare
2b4da9d
to
c16d446
Compare
Signed-off-by: Jakub Jelen <[email protected]>
Signed-off-by: Jakub Jelen <[email protected]>
Signed-off-by: Jakub Jelen <[email protected]>
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]>
c16d446
to
da33f19
Compare
There was a problem hiding this 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!
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