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)
The latest change misdocumented OSSL_PARAM_get_utf8_string(), that
change should have been for OSSL_PARAM_set_utf8_string().
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16318)
This fixes numerous bugs in documentation in regards to UTF8
params and their sizes. The returned size should always be without the
terminating NUL byte. On the other hand on the requestor side
the size of the buffer should include the NUL byte if it expects it
being included in the returned string.
Also make this clear in the EVP_PKEY_get_group_name() documentation
which uses utf8 string params under the hood.
Fixes#16287
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16296)
This macro was added since 1.1.1 and was undocumented.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14232)
When the string "ABCDEFGH" is passed, what's considered its data, this?
{ 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H' }
or this?
{ 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', '\0' }
If it's passed as a pass phrase, should the terminating NUL byte be
considered part of the pass phrase, or not?
Our treatment of OSSL_PARAMs with the data type OSSL_PARAM_UTF8_STRING
set the length of the string to include the terminating NUL byte,
which is quite confusing. What should the recipient of such a string
believe?
Instead of perpetuating this confusion, we change the assumption to
set the OSSL_PARAM to the length of the string, not including the
terminating NUL byte, thereby giving it the same value as a strlen()
call would give.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14168)
Since the pointer can be later be modified, the caller should have the
responsibility to supply the address of that.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13951)
Details from man-pages(7) that are used:
Formatting conventions for manual pages describing functions
...
Variable names should, like argument names, be specified in italics.
...
Formatting conventions (general)
...
Special macros, which are usually in uppercase, are in bold.
Exception: don't boldface NULL.
...
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13848)
When some function receives an OSSL_PARAM array to pilfer for data,
and there is a string of some sort, and all the code needs is to get
the pointer to the data, rather than a copy, there is currently no
other way than to use |param->data| directly. This is of course a
valid method, but lacks any safety check (is |param->data_type|
correct, for example?).
OSSL_PARAM_get_utf8_string_ptr() and OSSL_PARAM_get_octet_string_ptr()
helps the programmer with such things, by setting the argument pointer
to |param->data|.
Additionally, the handle the data types OSSL_PARAM_UTF8_PTR and
OSSL_PARAM_OCTET_PTR as well.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
CLA: trivial
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12320)
POSIX mandates that time_t is a signed integer but it doesn't specify the
lenght. Having wrappers lets uses ignore this.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/11682)
We may just want to know the number of octets so allow passing a NULL
buffer.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11635)
It is better, safer and smaller to let the library routine handle the
strlen(3) call.
Added a note to the documentation suggesting this.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11019)
OpenSSL uses some POD directives masquerading as 'comment'
('=for comment' etc). This is abusive and confusing. Instead, we use
our own keyword.
=for openssl whatever
=begin openssl
whatever
=end openssl
(we have never used the multiline form, but might start one day)
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10048)
If the passed string length is zero, the function computes the string length
from the passed string.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9760)
3.0.0 is a habit from pre-3.0 OpenSSL, which doesn't make sense with
the new version scheme.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9376)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9288)
Instead of referencing the return size from the OSSL_PARAM structure, make the
size a field within the structure.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9135)
