They do the same thing as OPENSSL_hexstr2buf() and OPENSSL_buf2hexstr(),
except they take a result buffer from the caller.
We take the opportunity to break out the documentation of the hex to /
from buffer conversion routines from the OPENSSL_malloc() file to its
own file. These routines aren't memory allocation routines per se.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9303)
A fuller implementation of PARAMS_TEMPLATE as per #9266 but renamed.
This introduces a statis data type which can be used to constructor a
description of a parameter array. It can then be converted into a OSSL_PARAM
array and the allocated storage freed by a single call to OPENSSL_free.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9305)
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)
This configuration module supports a configuration structure pretty
much like the engine configuration module, i.e. something like this:
openssl_conf = openssl_init
[openssl_init]
providers = provider_section
[provider_section]
# Configure the provider named "foo"
foo = foo_section
# Configure the provider named "bar"
bar = bar_section
[foo_section]
# Override name given in the provider section
identity = myfoo
# The exact path of the module. This is platform specific
module_path = /opt/openssl/modules/foo.so
# Whether it should be automatically activated. Value is unimportant
activate = whatever
# Anything else goes as well, and becomes parameters that the
# provider can get
what = 1
# sub-sections will be followed as well
ever = ever_section
[ever_section]
cookie = monster
All the configurations in a provider section and its sub-sections
become parameters for the provider to get, i.e. the "foo" provider
will be able to get values for the following keys (with associated
values shown):
identity => myfoo
module_path => /opt/openssl/modules/foo.so
activate => whatever
what => 1
ever.cookie => monster
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8549)
Provider parameters are parameters set by the core that the provider
can retrieve. The primary use it to support making OpenSSL
configuration data available to the provider.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8549)
OpenSSL will come with a set of well known providers, some of which
need to be accessible from the start. These are typically built in
providers, or providers that will work as fallbacks.
We do this when creating a new provider store, which means that this
will happen in every library context, regardless of if it's the global
default one, or an explicitely created one.
We keep the data about the known providers we want to make accessible
this way in crypto/provider_predefined.h, which may become generated.
For now, though, we make it simple and edited manually.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8480)
To ensure that old applications aren't left without any provider, and
at the same time not forcing any default provider on applications that
know how to deal with them, we device the concept of fallback
providers, which are automatically activated if no other provider is
already activated.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8480)
Adding a provider means creating an internal provier object and adding
it to the store. This allows the addition of built in providers, be it
in the OpenSSL libraries or in any application.
"Loading" a provider is defined broadly. A built in provider is already
"loaded" in essence and only needs activating, while a provider in a
dynamically loadable module requires actually loading the module itself.
In this API, "loading" a provider does both.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
The OSSL_PROVIDER is the core object involved in loading a provider
module, initialize a provider and do the initial communication of
provider wide and core wide dispatch tables.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8287)
Run perltidy on util/mkerr
Change some mkerr flags, write some doc comments
Make generated tables "const" when genearting lib-internal ones.
Add "state" file for mkerr
Renerate error tables and headers
Rationalize declaration of ERR_load_XXX_strings
Fix out-of-tree build
Add -static; sort flags/vars for options.
Also tweak code output
Moved engines/afalg to engines (from master)
Use -static flag
Standard engine #include's of errors
Don't linewrap err string tables unless necessary
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3392)
If init failed we'd like to set an error code to indicate that. But if
init failed then when the error system tries to load its strings its going
to fail again. We could get into an infinite loop. Therefore we just set
a single error the first time around. After that no error is set.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Rename BUF_{strdup,strlcat,strlcpy,memdup,strndup,strnlen}
to OPENSSL_{strdup,strlcat,strlcpy,memdup,strndup,strnlen}
Add #define's for the old names.
Add CRYPTO_{memdup,strndup}, called by OPENSSL_{memdup,strndup} macros.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Add CRYPTO_free_ex_index (for shared libraries)
Unify and complete the documentation for all "ex_data" API's and objects.
Replace xxx_get_ex_new_index functions with a macro.
Added an exdata test.
Renamed the ex_data internal datatypes.
Reviewed-by: Matt Caswell <matt@openssl.org>
Rebuild error source files: the new mkerr.pl functionality will now
pick up and translate static function names properly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Removed ability to set ex_data impl at runtime. This removed these
three functions:
const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void);
int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i);
int CRYPTO_ex_data_new_class(void);
It is no longer possible to change the ex_data implementation at
runtime. (Luckily those functions were never documented :)
Also removed the ability to add new exdata "classes." We don't believe
this received much (if any) use, since you can't add it to OpenSSL objects,
and there are probably better (native) methods for developers to add
their own extensible data, if they really need that.
Replaced the internal hash table (of per-"class" stacks) with a simple
indexed array. Reserved an index for "app" application.
Each API used to take the lock twice; now it only locks once.
Use local stack storage for function pointers, rather than malloc,
if possible (i.e., number of ex_data items is under a dozen).
Make CRYPTO_EX_DATA_FUNCS opaque/internal.
Also fixes RT3710; index zero is reserved.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).
This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.
The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.
Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
be needed in some ENGINE code, and might serve elsewhere as well.
Note that it's implemented in such a way that the locking itself is
done through the same CRYPTO_lock function as the static locks.
WARNING: This is currently experimental and untested code (it will get
tested soon, though :-)).
script, translates function codes better and doesn't need the K&R function
prototypes to work (NB. the K&R prototypes can't be wiped just yet: they are
still needed by the DEF generator...). I also ran the script with the -rewrite
option to update all the header and source files.
