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)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9275)
When bufsize == 0, openssl_strerror_r should return 0 (if _GNU_SOURCE is defined),
to be consistent with non-_GNU_SOURCE variants, which exhibit the same behavior.
Fix a few cases, where the return value of openssl_strerror_r was ignored.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9163)
This happens on systems that perform is* character classifictions as
array lookup, e.g. NetBSD.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6584)
It's a convenient complement to OSSL_STORE_ctrl()
Suggested by Norm Green
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5363)
Conceptually, this is a squashed version of:
Revert "Address feedback"
This reverts commit 75551e07bd.
and
Revert "Add CRYPTO_thread_glock_new"
This reverts commit ed6b2c7938.
But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.
The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions! The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.
However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL. That is, we can consider four cases of forking application
that might use OpenSSL:
(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)
For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).
(2) Single-threaded, calls into OpenSSL after fork()
The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock). Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.) If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.
(3) Multi-threaded, does not call into OpenSSL after fork()
As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed. The internal locks
are relevant, but there is no interaction with the child to consider.
(4) Multi-threaded, calls into OpenSSL after fork()
This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion. However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions. Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation. So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().
In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)
Expression '...' is always true.
The 'b->init' variable is assigned values twice successively
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4753)
This quiets down complaints about the use of uninitialised memory
[extended tests]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4340)
cryptilib.h is the second.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4188)
return true for characters > 127. I.e. they are allowing extended ASCII
characters through which then cause problems. E.g. marking superscript '2' as
a number then causes the common (ch - '0') conversion to number to fail
miserably. Likewise letters with diacritical marks can also cause problems.
If a non-ASCII character set is being used (currently only EBCDIC), it is
adjusted for.
The implementation uses a single table with a bit for each of the defined
classes. These functions accept an int argument and fail for
values out of range or for characters outside of the ASCII set. They will
work for both signed and unsigned character inputs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4102)
Since OSSL_STORE_open() tries with the 'file' scheme loader first, and
then on the loader implied by the URI if the former fails, the former
leaves an error on the error stack. This is confusing, so let's clear
the error stack on success. The implementation uses ERR_set_mark,
ERR_pop_to_mark and ERR_clear_last_mark to make sure caller errors are
preserved as much as possible.
Fixes#4089
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4094)
If we have a local file with a name starting with 'file:', we don't
want to check if the part after 'file:' is absolute. Instead, mark
each possibility for absolute check if needed, and perform the
absolute check later on, when checking each actual path.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
To handle paths that contain devices (for example, C:/foo/bar.pem on
Windows), try to "open" the URI using the file scheme loader first,
and failing that, check if the device is really a scheme we know.
The "file" scheme does the same kind of thing to pick out the path
part of the URI.
An exception to this special treatment is if the URI has an authority
part (something that starts with "//" directly after what looks like a
scheme). Such URIs will never be treated as plain file paths.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3907)
With added commenting to describe the individual decoders a little
more.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3930)
The way try_decode_params works in raw more, it would take the first ASN1
that could decode and return a STORE_INFO with the resulting EVP_PKEY.
This change has it go through all the matching ASN1 methods and properly
check if there's more than one match, i.e. an ambiguity.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3863)
The post process callback might potentially say "no" to everything (by
constantly returning NULL) and thereby cause an endless loop. Ensure
that we stop all processing when "eof" is reached.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/3823)
Most of the loader function pointers are crucial, they must be defined
unconditionally. Therefore, let's make sure OSSL_STORE_register_loader
refuses to register incomplete loaders
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3805)
We have already made sure that the loader scheme isn't NULL, so
checking if they are NULL or not when comparing registered loaders
is redundant. We still soft assert it, just to be entirely sure.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3805)
store_attach_pem_bio() creates a STORE_CTX with the 'file' scheme
loader backend in PEM reading mode on an already opened BIO.
store_detach_pem_bio() detaches the STORE_CTX from the BIO and
destroys it (without destroying the BIO).
These two functions can be used in place of STORE_open() and
STORE_close(), and are present as internal support for other OpenSSL
functions.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2745)
Sometimes, 'file_load' couldn't really distinguish if a file handler
matched the data and produced an error or if it didn't match the data
at all.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
This has it recognised when the given path is a directory. In that
case, the file loader will give back a series of names, all as URI
formatted as possible given the incoming URI.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
Add a separate handler for encrypted PKCS#8 data. This uses the new
restart functionality.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
Some containers might very simply decode into something new that
deserves to be considered as new (embedded) data. With the help of a
special OSSL_STORE_INFO type, make that new data available to the
loader functions so they can start over.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
Containers are objects that are containers for a bunch of other
objects with types we recognise but aren't readable in a stream. Such
containers are read and parsed, and their content is cached, to be
served one object at a time.
This extends the FILE_HANDLER type to include a function to destroy
the cache and a function to simulate the EOF check.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
This STORE module adds the following functionality:
- A function OSSL_STORE_open(), OSSL_STORE_load() and OSSL_STORE_close()
that accesses a URI and helps loading the supported objects (PKEYs,
CERTs and CRLs for the moment) from it.
- An opaque type OSSL_STORE_INFO that holds information on each loaded
object.
- A few functions to retrieve desired data from a OSSL_STORE_INFO
reference.
- Functions to register and unregister loaders for different URI
schemes. This enables dynamic addition of loaders from applications
or from engines.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)
