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

Make EVP_PKEY_CTX initialization more precise #10308

Closed
wants to merge 2 commits into from

Conversation

@levitte
Copy link
Member

levitte commented Oct 31, 2019

There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.

This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.

Additionally, we change EVP_PKEY_CTX_new_provided() to take a library
context alongside the algorithm name and property query string.

There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.

This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.
@levitte levitte added this to the 3.0.0 milestone Oct 31, 2019
@levitte levitte added this to In progress in 3.0 New Core + FIPS via automation Oct 31, 2019
@mattcaswell mattcaswell self-assigned this Nov 1, 2019
3.0 New Core + FIPS automation moved this from In progress to Reviewer approved Nov 1, 2019
@levitte levitte dismissed mattcaswell’s stale review Nov 1, 2019

I'll add the necessary code to include the library context in the new_provided case, so will need re-review

3.0 New Core + FIPS automation moved this from Reviewer approved to Needs review Nov 1, 2019
@levitte levitte removed the approval: done label Nov 1, 2019
@levitte levitte changed the title Make EVP_PKEY_CTX initialization more precise WIP: Make EVP_PKEY_CTX initialization more precise Nov 1, 2019
With provided algorithms, the library context is ever present, so of
course it should be specified alongside the algorithm name and
property query string.
@levitte levitte changed the title WIP: Make EVP_PKEY_CTX initialization more precise Make EVP_PKEY_CTX initialization more precise Nov 1, 2019
@levitte

This comment has been minimized.

Copy link
Member Author

levitte commented Nov 1, 2019

Please review again

3.0 New Core + FIPS automation moved this from Needs review to Reviewer approved Nov 1, 2019
Copy link
Member

mattcaswell left a comment

LGTM

@levitte

This comment has been minimized.

Copy link
Member Author

levitte commented Nov 1, 2019

CIs are happy too

openssl-machine pushed a commit that referenced this pull request Nov 3, 2019
There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.

This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10308)
openssl-machine pushed a commit that referenced this pull request Nov 3, 2019
With provided algorithms, the library context is ever present, so of
course it should be specified alongside the algorithm name and
property query string.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10308)
@levitte

This comment has been minimized.

Copy link
Member Author

levitte commented Nov 3, 2019

Merged.

60653e5 Make EVP_PKEY_CTX initialization more precise
3ee348b Change EVP_PKEY_CTX_new_provided() to take a library context too.

@levitte levitte closed this Nov 3, 2019
3.0 New Core + FIPS automation moved this from Reviewer approved to Done Nov 3, 2019
DDvO added a commit to siemens/openssl that referenced this pull request Nov 5, 2019
There is a vagueness around how the provider data (algorithm name and
property query string) is initialized in the presence of an engine.
This change modifies this slightly so that the algorithm name for use
with providers is never set if the initilization was given an engine.

This makes it easier for other functions to simply check ctx->algorithm
to see if the context is meant to be used for strictly legacy stuff or
not.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from openssl#10308)
DDvO added a commit to siemens/openssl that referenced this pull request Nov 5, 2019
With provided algorithms, the library context is ever present, so of
course it should be specified alongside the algorithm name and
property query string.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from openssl#10308)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.