Rename the field 'provctx and data' to 'algctx' inside some EVP objects. #15275
Conversation
This file contains 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
slontis
added
branch: master
slontis
commented
May 14, 2021
github-actions
bot
added
the
severity: fips change
levitte
requested changes
May 14, 2021
|
Side note: I like what the checksums github action does. Nice work @t8m! |
…ontaining pointers to provider size algorithm contexts. Fixes openssl#14284 The gettable_ctx_params methods were confusingly passing a 'provctx' and a provider context which are completely different objects. Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'. For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm implementation creates an internal context using a new_ctx() method. Hence the new name 'algctx'.
slontis
force-pushed
the
provctx_rename_to_data
branch
from
6a72770
to
9de3780
Compare
slontis
changed the title
|
Changed all of them to use algctx |
levitte
requested changes
May 18, 2021
| /* | ||
| * Opaque ctx returned from a providers digest algorithm implementation | ||
| * OSSL_FUNC_digest_newctx() | ||
| */ |
There was a problem hiding this comment.
This comment seems a bit bloated at this point. How about /* Algorithm-specific ctx */?
There was a problem hiding this comment.
I prefer the longer comment.
There was a problem hiding this comment.
So why only here and not everywhere where we have the algctx field?
There was a problem hiding this comment.
Change to make them all more verbose noted.
I find it amazing, though, that extended verbosity is chosen for this item specifically. I kinda understand it considering that there seems to be a lot of confusion... but in a year, will we still feel the same?
There was a problem hiding this comment.
Anyway, I'm not going to block on terms of verbosity, just wanted to express my surprise over this choice, this time
There was a problem hiding this comment.
This may be trying to be kind to others trying to understand what it is.
| /* | ||
| * Opaque ctx returned from a providers cipher algorithm implementation | ||
| * OSSL_FUNC_cipher_newctx() | ||
| */ |
There was a problem hiding this comment.
This comment seems a bit bloated at this point. How about /* Algorithm-specific ctx */?
paulidale
approved these changes
May 18, 2021
paulidale
added
approval: done
openssl-machine
added
approval: ready to merge
|
This pull request is ready to merge |
…jects containing pointers to provider size algorithm contexts.
|
Changed the comments.. |
levitte
requested changes
May 20, 2021
…jects containing pointers to provider size algorithm contexts.
levitte
approved these changes
May 20, 2021
t8m
approved these changes
May 21, 2021
|
Merged to master. |
openssl-machine
pushed a commit
that referenced
this pull request
May 24, 2021
…ontaining pointers to provider size algorithm contexts. Fixes #14284 The gettable_ctx_params methods were confusingly passing a 'provctx' and a provider context which are completely different objects. Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'. For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm implementation creates an internal context using a new_ctx() method. Hence the new name 'algctx'. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #15275)
|
Thanks Pauli.. |
devnexen
pushed a commit
to devnexen/openssl
that referenced
this pull request
Jul 7, 2021
…ontaining pointers to provider size algorithm contexts. Fixes openssl#14284 The gettable_ctx_params methods were confusingly passing a 'provctx' and a provider context which are completely different objects. Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'. For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm implementation creates an internal context using a new_ctx() method. Hence the new name 'algctx'. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#15275)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #14284
This was a bit confusing since some objects need an actual provider
context to be passed (e.g. asym_cipher_gettable_ctx_params)
This 'data' field is an opaque ptr returned from new_ctx() operations. The
ptr points to data created inside a providers implementation of an
algorithm. This ptr is then passed to the provider algorithm for all
subsequent operations (such as init(), update(), and free()).
Checklist