Fixes a problem where global properties don't work with a NULL query.
Specifying an algorithm with a NULL query ignores the default properties.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12123)
This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.
Fixes#11538
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11539)
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)
The reduction in the cache flush threshold in #10408 caused the stochastic test
to fail with noticeable probability. Revert that part of the change.
Also add a comment to help avoid this in future.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10505)
The property query cache was not reference count aware and this could cause
problems if the property store removes an algorithm while it is being returned
from an asynchronous query. This change makes the cache reference count aware
and avoids disappearing algorithms.
A side effect of this change is that the reference counts are now owned by the
cache and store.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10408)
We put almost everything in these internal static libraries:
libcommon Block building code that can be used by all
our implementations, legacy and non-legacy
alike.
libimplementations All non-legacy algorithm implementations and
only them. All the code that ends up here is
agnostic to the definitions of FIPS_MODE.
liblegacy All legacy implementations.
libnonfips Support code for the algorithm implementations.
Built with FIPS_MODE undefined. Any code that
checks that FIPS_MODE isn't defined must end
up in this library.
libfips Support code for the algorithm implementations.
Built with FIPS_MODE defined. Any code that
checks that FIPS_MODE is defined must end up
in this library.
The FIPS provider module is built from providers/fips/*.c and linked
with libimplementations, libcommon and libfips.
The Legacy provider module is built from providers/legacy/*.c and
linked with liblegacy, libcommon and libcrypto.
If module building is disabled, the object files from liblegacy and
libcommon are added to libcrypto and the Legacy provider becomes a
built-in provider.
The Default provider module is built-in, so it ends up being linked
with libimplementations, libcommon and libnonfips. For libcrypto in
form of static library, the object files from those other libraries
are simply being added to libcrypto.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)
The random bit caching was a residue of earlier code and isn't used any more.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10089)
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 output C code was made to use ERR_func_error_string() to see if a
string table was already loaded or not. Since this function returns
NULL always, this check became useless.
Change it to use ERR_reason_error_string() instead, as there's no
reason to believe we will get rid of reason strings, ever.
To top it off, we rebuild all affected C sources.
Fixes#9756
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9756)
Simplify the initialisation of the core by pre-initialising properties.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9590)
If ossl_method_store_add() gets called with a method that already exists
(i.e. the store has one with matching provider, nid and properties), that
method should not be stored. We do this check inside ossl_method_store_add()
because it has all the locking required to do so safely.
Fixes#9561
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9650)
Because this function affects the reference count on failure (the call
to impl_free() does this), it may as well handle incrementing it as
well to indicate the extra reference in the method store.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9650)
Previously we only loaded the config file by default for libssl. Now we do
it for libcrypto too.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9492)
The problem being that the "requires flush" flag was being cleared after the
the flush. The fix is to clear it before. This is a problem because the
cache flushing called RAND_bytes and if the DRBG hadn't been created yet, it
would be queried and added to the cache causing the flush code to repeat.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/9477)
The alternative is to use a fast and small xorshift
random number generator. The stochastic flushing doesn't require good
random numbers, just enough variety to avoid causing problems.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/9477)
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 a page about properties in the man7 section of the public documentation.
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/9011)
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)
The comparator further down the call stack doesn't tolerate NULL, so
if we got that as input, use the empty string.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8781)
This should never reduce the range covered and might increase it on some
platforms.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8415)
- Add a bit more text about that is expected of the user or
OSSL_METHOD_STOREs.
- Clarify what a method and what a numeric identity are.
- Change all mentions of 'implementation' and 'result' to 'method'.
To clarify further: OpenSSL has used the term 'method' for structures
that mainly contains function pointers. Those are the methods that
are expected to be stored away in OSSL_METHOD_STOREs. In the end,
however, it's the caller's responsibility to define exactly what they
want to store, as long as its 'methods' are associated with a numeric
identity and properties.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8265)
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)
