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)
Fixes#14041 and additional bugs discovered by the newly created
tests.
This patch:
- Introduces support for 0x prefixed integers
- Fixes parsing of negative integers (negative numbers were
shifted by -2)
- Fixes ability to parse maximal unsigned numbers ("too small
buffer" error used to be reported incorrectly)
- Fixes a memory leak when OSSL_PARAM_allocate_from_text fails
leaving a temporary BN allocated
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14093)
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)
Before the return size was included in the OSSL_PARAM structure, the size
global was updated via a pointer. The size global variable has been removed
and the in structure return size used instead.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9248)
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)
When the purpose is to pass parameters to a setter function, that
setter function needs to know the size of the data passed. This
remains true for the pointer data types as well.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8703)
OSSL_PARAM_END is a macro that can only be used to initialize an
OSSL_PARAM array, not to assign an array element later on. For
completion, we add an end constructor to facilitate that kind of
assignment.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8704)
TEST_ulong_eq was used previously because TEST_double_eq didn't exist
at the time.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8469)
With enough warning flags, compilers complain when a non-static
function hasn't been properly declared...
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8469)
test/params_test.c is a program that tries to mimic how a provider and
an application would or could handle OSSL_PARAM arrays.
For the moment, this program tests a very raw way of handling
OSSL_PARAM arrays. It is, however, written in a way that will
hopefully make it possible to extend with other methods as APIs arise,
and to set up test cases where a "provider" handles the array one way
while the "application" handles it another way.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8396)
