| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The base type OSSL_PARAM getters will NULL deref if they are initalized
as null. Add NULL checks for those parameters that have no expectation
of returning null (int32/64/uint32/64/BN). Other types can be left as
allowing NULL, as a NULL setting may be meaningful (string, utf8str,
octet string, etc).
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23083)
|
|
|
|
|
| |
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Release: yes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a big endian machine, we get test failures in params_api_test like
# ERROR: (memory) 'buf1 == buf2' failed @ test/params_api_test.c:473
# --- buf1
# +++ buf2
# 0000:-e901
# 0000:+01e9
# ^^^^
#
# OPENSSL_TEST_RAND_ORDER=1643313367
not ok 157 - iteration 3
They are due to an additional conversion copy. Remove this copy to solve the
problem.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17608)
|
|
|
|
|
| |
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17162)
|
|
|
|
|
|
| |
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17392)
|
|
|
|
|
|
|
| |
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16918)
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions are prerequisites for implementing EVP_PKEY_todata().
OSSL_PARAM_dup() is required to make a deep copy of the exported
params (since the provider export() uses a OSSL_PARAM_BLD which throws away the
data after the call), and then use OSSL_PARAM_merge() to add some additional params
that can be passed to the EVP_PKEY_todata().
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14785)
|
|
|
|
|
| |
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14596)
|
|
|
|
|
|
|
|
|
| |
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14582)
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14512)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13663)
|
|
|
|
|
|
|
|
|
| |
This moves test/ossl_test_endian.h to include/internal/endian.h and
thereby makes the macros in there our standard way to check endianness
in run-time.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/12390)
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11601)
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11616)
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11588)
|
|
|
|
|
|
|
|
| |
Now, the returned size check matches the check made for all other
integer types.
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
(Merged from https://github.com/openssl/openssl/pull/10326)
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
Using a byte buffer causes problems for device that don't handle unaligned
reads. Instead use the properly aligned variable that was already pointed at.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8696)
|
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/8629)
|
|
|
|
|
|
|
|
| |
/usr/include/bits/waitstatus.h includes endian.h under some libc's.
This clashes with the new test header file, so rename the latter.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8600)
|
|
|
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8572)
|
|
|
|
|
|
|
| |
Free the allocated pointer on error.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8503)
|
|
|
|
|
|
|
|
|
| |
size_t isn't always as large as a int64_t, so the compiler complains
about possible data loss. In this case, we are in control, so a
simple cast will do.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8497)
|
|
Provide a number of functions to allow parameters to be set and
retrieved in a type safe manner. Functions are provided for many
integral types plus double, BIGNUM, UTF8 strings and OCTET strings.
All of the integer functions will widen the parameter data as
required. This permits a degree of malleability in the parameter
definition. For example a type can be changed from a thirty two bit
integer to a sixty four bit one without changing application code.
Only four and eight byte integral sizes are supported here.
A pair of real functions are available for doubles.
A pair of functions is available for BIGNUMs. These accept any sized
unsigned integer input and convert to/from a BIGNUM.
For each OCTET and UTF8 strings, four functions are defined. This
provide get and set functionality for string and for pointers to
strings. The latter avoiding copies but have other inherent risks.
Finally, some utility macros and functions are defined to allow
OSSL_PARAM definition arrays to be specified in a simple manner.
There are two macro and one function for most types. The exception
being BIGNUM, for which there is one macro and one function.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8451)
|