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)
ctx may be NULL at 178 line
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17293)
When the user expects to load a certificate or a CRL through the
OSSL_STORE loading function, the 'file:' implementation sets the
corresponding structure names in the internal decoder context.
This is especially geared for PEM files, which often contain a mix of
objects, and password prompting should be avoided for objects that
need them, but aren't what the caller is looking for.
Fixes#16224
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
The 'file:' store loader only understood DER natively. With all the
whatever to key decoders gone, direct support for other binary file
formats are gone, and we need to recreate them for this store loader.
With these changes, it now also understands MSBLOB and PVK files.
As a consequence, any store loader that handles some form of open file
data (such as a PEM object) can now simply pass that data back via
OSSL_FUNC_store_load()'s object callback. As long as libcrypto has
access to a decoder that can understand the data, the appropriate
OpenSSL object will be generated for it, even if the store loader sits
in a different provider than any decoder or keymgmt.
For example, an LDAP store loader, which typically finds diverse PEM
formatted blobs in the database, can simply pass those back via the
object callback, and let libcrypto do the rest of the work.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15981)
This makes the 'file:' store loader only read the file, and only decode
down to a base level binary format, and simply pass that blob of data
back to the OSSL_FUNC_store_load() object callback.
This offloads the decoding into specific OpenSSL types to libcrypto,
which takes away the issue of origins, which provider is it that holds
the key (or other future types of objects).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15981)
They aren't needed at all any more, since the properties contain the
same information.
This also drops the parameter names OSSL_DECODER_PARAM_INPUT_TYPE
and OSSL_DECODER_PARAM_INPUT_STRUCTURE.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
libimplementations.a was a nice idea, but had a few flaws:
1. The idea to have common code in libimplementations.a and FIPS
sensitive helper functions in libfips.a / libnonfips.a didn't
catch on, and we saw full implementation ending up in them instead
and not appearing in libimplementations.a at all.
2. Because more or less ALL algorithm implementations were included
in libimplementations.a (the idea being that the appropriate
objects from it would be selected automatically by the linker when
building the shared libraries), it's very hard to find only the
implementation source that should go into the FIPS module, with
the result that the FIPS checksum mechanism include source files
that it shouldn't
To mitigate, we drop libimplementations.a, but retain the idea of
collecting implementations in static libraries. With that, we not
have:
libfips.a
Includes all implementations that should become part of the FIPS
provider.
liblegacy.a
Includes all implementations that should become part of the legacy
provider.
libdefault.a
Includes all implementations that should become part of the
default and base providers.
With this, libnonfips.a becomes irrelevant and is dropped.
libcommon.a is retained to include common provider code that can be
used uniformly by all providers.
Fixes#15157
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15171)
Add OSSL_STORE_PARAM_INPUT_TYPE and make it possible to be
set when OSSL_STORE_open_ex() or OSSL_STORE_attach() is called.
The input type format is enforced only in case the file
type file store is used.
By default we use FORMAT_UNDEF meaning the input type
is not enforced.
Fixes#14569
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15100)
In the provider file: scheme loader implementation, the OSSL_DECODER_CTX
was set up with all sorts of implementations, even if the caller has
declared a limited expectation on what should be loaded, which means
that even though a certificate is expected, all the diverse decoders
to produce an EVP_PKEY are added to the decoding change.
This optimization looks more closely at the expected type, and only
adds the EVP_PKEY related decoder implementations to the chain if
there is no expectation, or if the expectation is one of
OSSL_STORE_INFO_PARAMS, OSSL_STORE_INFO_PUBKEY, OSSL_STORE_INFO_PKEY.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15066)
We do here like in all other decoder implementations, drop all errors
that were caused by a failing asn1_d2i_read_bio(), as it's most likely
to mean that the input isn't DER, and another decoder implementation,
if there is any left, should have a go.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/15008)
This includes the special decoder used in our STOREMGMT 'file:' implementation
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14834)
This corresponds to the |info| field in EVP_PKEY_ASN1_METHOD, as well
as the generic use of OBJ_nid2ln() as a one line description.
We also add the base functionality to make use of this field.
Fixes#14514
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14656)
Providers (particularly the FIPS provider) needs access to BIOs from libcrypto.
Libcrypto is allowed to change the internal format of the BIO structure and it
is still expected to work with providers that were already built. This means
that the libcrypto BIO must be distinct from and not castable to the provider
side OSSL_CORE_BIO.
Unfortunately, this requirement was broken in both directions. This fixes
things by forcing the two to be different and any casts break loudly.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14419)
Fixes#13185Fixes#13352
Removed the existing code in file_store that was trying to figure out the
input type.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14407)
Additional renames done in encoder and decoder implementation
to follow the style.
Fixes#13622
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14155)
The PROV_R codes can be returned to applications so it is useful
to have some common set of provider reason codes for the applications
or third party providers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14086)
Refactor them into inline ossl_ends_with_dirsep function in
internal/cryptlib.h.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13306)
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
The following internal functions are affected:
ossl_do_blob_header
ossl_do_PVK_header
ossl_b2i
ossl_b2i_bio
This is reflected by moving include/internal/pem.h to include/crypto/pem.h
engines/e_loader_attic gets the source code added to it to have
continued access to those functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13195)
This change makes the naming more consistent, because three different terms
were used for the same thing. (The term libctx was used by far most often.)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
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)
There is some data that is very difficult to guess. For example, DSA
parameters and X9.42 DH parameters look exactly the same, a SEQUENCE
of 3 INTEGER. Therefore, callers may need the possibility to select
the exact keytype that they expect to get.
This will also allow use to translate d2i_TYPEPrivateKey(),
d2i_TYPEPublicKey() and d2i_TYPEParams() into OSSL_DECODER terms much
more smoothly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13061)
This stops them leaking into other namespaces in a static build.
They remain internal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13013)
This replaces the older 'file:' loader that is now an engine.
It's still possible to use the older 'file:' loader by explicitly
using the engine, and tests will remain for it as long as ENGINEs are
still supported (even through deprecated).
To support this storemgmt implementation, a few internal OSSL_DECODER
modifications are needed:
- An internal function that implements most of
OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already
existing OSSL_DECODER_CTX instead of allocating a new one.
- Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM.
It isn't attached to any provider, and is only used internally, to
simply catch any DER encoded object to be passed back to the
object callback with no further checking. This implementation
becomes the last resort decoder, when all "normal"
decodation attempts (i.e. those that are supposed to result
in an OpenSSL object of some sort) have failed.
Because file_store_attach() uses BIO_tell(), we must also support
BIO_ctrl() as a libcrypto upcall.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
