History log of /openssl/doc/man7/provider-decoder.pod (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...