Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)
Test the next arithmetic operation to safely determine if adding the
next digit in the passed property string will overflow
Also, noted a bug in the parse_hex code. When parsing non-digit
characters (i.e. a-f and A-F), we do a tolower conversion (which is
fine), and then subtract 'a' to get the hex value from the ascii (which
is definately wrong). We should subtract 'W' to convert tolower
converted hex digits in the range a-f to their hex value counterparts
Add tests to test_property_parse_error to ensure overflow checks work
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/22874)
ossl_property_list_to_string() didn't quote strings correctly which
could result in a generated property string being unparsable.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22182)
This fixes a warning from latest gcc.
There is no point in using strncpy here as we
intentionally copy only the string contents without
the terminating NUL. The len is set from strlen().
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/18627)
Including e_os.h with a path from a header file doesn't work well on
certain exotic platform. It simply fails to build.
Since we don't seem to be able to stop ourselves, the better move is
to move e_os.h to an include directory that's part of the inclusion
path given to the compiler.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17641)
These global variables were previously overwritten with the same value
every time we created a new OSSL_LIB_CTX. Instead we preinitialise them
with the correct values, and then confirm that settings for each
OSSL_LIB_CTX agree with the preinitialised values.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16980)
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)
Neither queries nor definitions handle duplicated property names well.
Make having such an error.
Fixes#16715
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16716)
This function searches a property list for a specific property and returns
a pointer to the definition if found. The existing version was O(n) time,
the improved O(log n).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15614)
This required making some OSSL_PROPERTY types a little less private.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
The int64_t type was converted to int (truncation).
Negative values were not handled at all.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15396)
We have the ability to parse a string into a PROPERTY_LIST already. Now
we have the ability to go the other way.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15242)
User defined property names were not created before the first fetch. The
rationale for this was to only maintain the user names defined by providers.
This was intended to prevent malicious memory use attacks.
Not being able to specify a default query before the first fetch is wrong. This
changes the behaviour of the property query parsing to always create property
names.
Fixes#15218
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15222)
Without this, it is necessary to query an algorithm before setting the default
property query. With this, the value will be created and the default will
work.
Fixes#14516
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14542)
Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.
The OPENSSL_CTX type stands out a little by using a different prefix.
For consistency reasons, this type is renamed to OSSL_LIB_CTX.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
This is part of an effort to make OSSL_ENCODER work more like OSSL_DECODER.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
This adds a method OSSL_DESERIALIZER, a deserializer context and basic
support to use a set of serializers to get a desired type of data, as
well as deserializer chains.
The idea is that the caller can call OSSL_DESERIALIZER_CTX_add_serializer()
to set up the set of desired results, and to add possible chains, call
OSSL_DESERIALIZER_CTX_add_extra(). All these deserializers are pushed
on an internal stack.
The actual deserialization is then performed using functions like
OSSL_DESERIALIZER_from_bio(). When performing deserialization, the
inernal stack is walked backwards, keeping track of the deserialized
data and its type along the way, until the data kan be processed into
the desired type of data.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12410)
Replace the properties default, fips and legacy with a single property
called "provider". So, for example, instead of writing "default=yes" to
get algorithms from the default provider you would instead write
"provider=default". We also have a new "fips" property to indicate that
an algorithm is compatible with FIPS mode. This applies to all the
algorithms in the FIPS provider, as well as any non-cryptographic
algorithms (currently only serializers).
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11097)
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)
The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form. The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.
We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.
Serializers are selected by method name and a couple of additional
properties:
- format used to tell what format the output should be in.
Possibilities could include "format=text",
"format=pem", "format=der", "format=pem-pkcs1"
(traditional), "format=der-pkcs1" (traditional)
- type used to tell exactly what type of data should be
output, for example "type=public" (the public part of
a key), "type=private" (the private part of a key),
"type=domainparams" (domain parameters).
This also adds a passphrase callback function type,
OSSL_PASSPHRASE_CALLBACK, which is a bit like OSSL_CALLBACK, but it
takes a few extra arguments to place the result in.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10394)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
The core now supplies its own versions of ERR_new(), ERR_set_debug()
and ERR_vset_error(). This should suffice for a provider to have any
OpenSSL compatible functionlity it desires.
The main difference between the ERR functions and the core
counterparts is that the core counterparts take an OSSL_PROVIDER
parameter instead of the library number. That way, providers do not
need to know what number they have been assigned, that information
stays in the core.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9452)
With properties being specified in all kinds of places, including hard
coded in providers, it's not always easy to figure out exactly what
string was incorrect when the parser would just say something like
'parse failed' with no more details.
Adding extra data to the error, showing exactly what string is
incorrect, helps a bit. At the very least, this gives anyone
interested something to grep for.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9190)
Add the possibility of a property query clause to be optional by preceding
it with a question mark.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8943)
Various core and property related code files used global data. We should
store all of that in an OPENSSL_CTX instead.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8857)
Properties are a sequence of comma separated name=value pairs. A name
without a corresponding value is assumed to be a Boolean and have the
true value 'yes'. Values are either strings or numbers. Strings can be
quoted either _"_ or _'_ or unquoted (with restrictions). There are no
escape characters inside strings. Number are either decimal digits or
'0x' followed by hexidecimal digits. Numbers are represented internally
as signed sixty four bit values.
Queries on properties are a sequence comma separated conditional tests.
These take the form of name=value (equality test), name!=value (inequality
test) or name (Boolean test for truth). Queries can be parsed, compared
against a definition or merged pairwise.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8224)
