Rethink the EVP_PKEY cache of provider side keys#11148
Merged
openssl-machine merged 4 commits intoopenssl:masterfrom Feb 29, 2020
Merged
Rethink the EVP_PKEY cache of provider side keys#11148openssl-machine merged 4 commits intoopenssl:masterfrom
openssl-machine merged 4 commits intoopenssl:masterfrom
Conversation
levitte
added
branch: master
2 tasks
Member
Author
|
A small note on evp_pkey_upgrade_to_provider(): This should never become a public function, for the simple reason that it's temporary, even though it's obvious that it will be around for a few years. The reason is that this duality between legacy keys and provider side keys is planned to go away when all the legacy stuff is gone, at which point the idea of an "upgrade" will be moot. |
Member
Author
|
This is WIP because I haven't updated the documentation yet. |
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
slontis
reviewed
Feb 22, 2020
Member
Author
|
I'm pondering if the separation between legacy "origin" and provider "origin" is a bit too strong. A slightly different model would be to have an upgrade simply use the legacy key as a template, and keep it around in case someone changes something in it... |
levitte
force-pushed
the
refactor-evp_pkey-provider-cache
branch
from
0fe97bf to
22de7e1
Compare
Member
Author
|
My pondering lead to mods, not here, but in #11158. Key upgrades must be used very carefully, the majority of cases only need to have a cached export. |
levitte
force-pushed
the
refactor-evp_pkey-provider-cache
branch
from
bce4d61 to
690e195
Compare
Member
Author
|
I did some squashing, for cleanup |
levitte
changed the title
Member
Author
|
Docs have been added, this is no longer WIP |
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
slontis
reviewed
Feb 24, 2020
Member
|
travis errors are relevant.. |
Member
Author
Fixed |
slontis
approved these changes
Feb 27, 2020
Member
slontis
left a comment
slontis
left a comment
There was a problem hiding this comment.
Approved - Provided the appveyor tests pass.
slontis
added
approval: done
openssl-machine
removed
the
approval: done
Collaborator
|
This pull request is ready to merge |
openssl-machine
added
the
approval: ready to merge
The role of this cache was two-fold:
1. It was a cache of key copies exported to providers with which an
operation was initiated.
2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was
the corresponding provider side origin, while the rest was the
actual cache.
This dual role for item 0 made the code a bit confusing, so we now
make a separate keymgmt / keydata pair outside of that cache, which is
the provider side "origin" key.
A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a
provider side "origin" at the same time.
Reviewed-by: Shane Lontis <[email protected]>
(Merged from openssl#11148)
This function "upgrades" a key from a legacy key container to a provider side key container. Reviewed-by: Shane Lontis <[email protected]> (Merged from openssl#11148)
Functions covered: - evp_pkey_export_to_provider() - evp_pkey_upgrade_to_provider() Reviewed-by: Shane Lontis <[email protected]> (Merged from openssl#11148)
Reviewed-by: Shane Lontis <[email protected]> (Merged from openssl#11148)
levitte
force-pushed
the
refactor-evp_pkey-provider-cache
branch
from
0026dbc to
e32c608
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The role of this cache was two-fold:
operation was initiated.
the corresponding provider side origin, while the rest was the
actual cache.
This dual role for item 0 made the code a bit confusing, so we now
make a separate keymgmt / keydata pair outside of that cache, which is
the provider side "origin" key.
A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a
provider side "origin" at the same time.
This also adds evp_pkey_upgrade_to_provider(), for EVP_PKEY upgrades