#
da1c088f |
| 07-Sep-2023 |
Matt Caswell |
Copyright year updates Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
|
#
04af51c2 |
| 13-Mar-2023 |
Andy Bernard |
Fix documented function return types The documented return type of the (incorrectly named; see below) OSSL_FUNC_decoder_export_object function signature is wrong; the correct type is int, du
Fix documented function return types The documented return type of the (incorrectly named; see below) OSSL_FUNC_decoder_export_object function signature is wrong; the correct type is int, due to the following line in core_dispatch.h: OSSL_CORE_MAKE_FUNC(int, decoder_export_object, Fixes #19543 Per the Github conversation with levitte and t8m for pull request #19964, the following issues are not addressed by this patch: The macro OSSL_CORE_MAKE_FUNC in core_dispatch.h generates a function, and a corresponding function signature typedef with name ending in "_fn". The typedefed signature is unrelated to the signature of the function. However, provider-decoder.pod describes typedefed signatures generated by the macro, but uses the names of the functions (lacking "_fn") instead of the typedefed signatures, which is a mismatch. Also, the documented claim about OSSL_FUNC_decoder_export_object, etc that "None of these are actual functions" is contradicted by the fact that the code actually calls those functions, and calls them specifically by those names. E.g. in decoder_meth.c: decoder->export_object = OSSL_FUNC_decoder_export_object(fns); The functions are generated by OSSL_CORE_MAKE_FUNC. The paragraph "None of these are actual functions"... should be replaced by something more like "These function signatures, generated by the OSSL_CORE_MAKE_FUNC macro, are for functions that are offered via function pointers in OSSL_DISPATCH arrays." CLA: trivial Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19964)
show more ...
|
#
318a9dfa |
| 05-Dec-2022 |
Richard Levitte |
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described i
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
show more ...
|
#
9379bf94 |
| 01-Jun-2021 |
Richard Levitte |
DECODER: use property definitions instead of getting implementation parameters The OSSL_DECODER library used to ask each decoder implementation for certain data in form of parameters to
DECODER: use property definitions instead of getting implementation parameters The OSSL_DECODER library used to ask each decoder implementation for certain data in form of parameters to place them correctly in the decoder chain, if at all. These parameters were duplicates of properties of those same implementations, and therefore unnecessarily redundant. Now that we have functionality to query property definition values, those duplicates are no longer needed, and are therefore not looked at any more. This adds the "global" error reason ERR_R_INVALID_PROPERTY_DEFINITION, which can be re-used elsewhere. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15570)
show more ...
|
Revision tags: openssl-3.0.0-alpha17, openssl-3.0.0-alpha16, openssl-3.0.0-alpha15 |
|
#
f9965953 |
| 12-Apr-2021 |
Richard Levitte |
ENCODER & DECODER: Allow decoder implementations to specify "carry on" So far, decoder implementations would return true (1) for a successful decode all the way, including what the callb
ENCODER & DECODER: Allow decoder implementations to specify "carry on" So far, decoder implementations would return true (1) for a successful decode all the way, including what the callback it called returned, and false (0) in all other cases. This construction didn't allow to stop to decoding process on fatal errors, nor to choose what to report in the provider code. This is now changed so that decoders implementations are made to return false only on errors that should stop the decoding process from carrying on with other implementations, and return true for all other cases, even if that didn't result in a constructed object (EVP_PKEY for example), essentially making it OK to return "empty handed". The success of the decoding process is now all about successfully constructing the final object, rather than about the return value of the decoding chain. If no construction is attempted, the central decoding processing code concludes that whatever the input consisted of, it's not supported by the available decoder implementations. Fixes #14423 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14834)
show more ...
|
Revision tags: openssl-3.0.0-alpha14 |
|
#
fdb5315b |
| 31-Mar-2021 |
Tomas Mraz |
provider-decoder.pod: Documentation of provider side decoder API Fixes #13949 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org>
provider-decoder.pod: Documentation of provider side decoder API Fixes #13949 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14756)
show more ...
|