-
Notifications
You must be signed in to change notification settings - Fork 291
Auto migrate p12 files with legacy encryption #1090
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
Conversation
|
/ost |
|
⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'. Follow the progress here. |
|
😭💔 ost suite 'basic-suite-master' on distro 'el9stream' failed. (details) |
|
/ost |
|
⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'. Follow the progress here. |
|
😭💔 ost suite 'basic-suite-master' on distro 'el9stream' failed. (details) |
First check that the needed db user is configured/present and only then look at the change_db flags. Signed-off-by: Peter Boden <[email protected]>
5158150 to
2ed5902
Compare
Add the concept of an install root to the engine-backup. On a regular production system the install root is `/`, but on development systems this root (i.e. installed from an rpm) can be anything. This makes it so that taking and restoring backups of development systems is impossible. There already was a devmode flag, if this flag is set to 1 then the INSTALL_ROOT will be equal to `$PREFIX/`, in all other cases the root will be `/` (like it was before). Also, use the 'ENGINE_USR' var where a hardcoded path was used. A backup that you take is now agnostic of the path where ovirt was/is installed. So you can restore a production backup on a dev box and vice versa. Signed-off-by: Peter Boden <[email protected]>
2ed5902 to
a883f53
Compare
|
/ost |
|
⏳ Running ost suite 'basic-suite-master' on distro 'el9stream'. Follow the progress here. |
|
😎💪 ost suite 'basic-suite-master' on distro 'el9stream' finished successfully. (details) |
packaging/bin/engine-backup.sh.in
Outdated
| local pki_password="$2" | ||
| local timestamp="$3" | ||
|
|
||
| log "Found legacy encryption in ${file}, re-encrypting to AES-256" |
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.
As we don't force AES-256, perhaps strip that from the output?
When restoring a backup from CentOS 8 onto a CentOS 9 system, the p12 files that were generated are invalid, because they use a legacy encryption on CentOS 9. So, upon restore, we try to read the p12 files. When this fails we try to read the p12 file with the `legacy` flag. If this succeeds, we re-encrypt the p12 file with a newer encryption algorythm. The old p12 files is backup up. We log all actions so that the user knows what happened, and can act upon errors. Signed-off-by: Peter Boden <[email protected]>
The `-aes256` flag is ignored by `openssl pkcs12 export`. We remove it and fall back to the default, which we assume is secure enough, and will stay more up-to-date while algorythms evolve. Signed-off-by: Peter Boden <[email protected]>
a883f53 to
31283a5
Compare
Changes introduced with this PR
This is the improved version of #1072 , which can probably be closed now.
And this also makes #932 obsolete.
Are you the owner of the code you are sending in, or do you have permission of the owner?
y