This allows the operating system sources that OpenSSL supports to be
used directly as RNGs. It also allows DRBG seeding to be explicitly
specified rather than being left to a fall back case.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13455)
For the moment, we translate the result to a NID, because that's still
used in several locations in libssl. Future development should change
all the internals to be name based instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13436)
This replaces the internal evp_pkey_get_EC_KEY_curve_nid()
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13436)
call level.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13394)
This commit clears the error that might have been set when
ossl_store_get0_loader_int has been called as it will try to retrieve
a loader for the scheme on an empty store, which will cause the error
OSSL_STORE_R_UNREGISTERED_SCHEME to be set.
The motivation for this after returning from
ossl_store_get0_loader_int, OSSL_STORE_attach will continue and try to
fetch a OSSL_STORE_LOADER from the provider.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12901)
The ERR_load_*_strings() functions were not being defined in a no-err
build. This is an API break since in 1.1.1 they were still present in a
no-err build, but were no-ops. This was also causing a failure in
test_symbol_presence. We revert to the way things were done in 1.1.1,
i.e. in a no-err build the functions are still present but are no-ops.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13598)
If we're using TLSv1.2 then the test_sigalgs_available test needs to be
careful which ciphersuite is selected in order for the test to behave
correctly.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13596)
This protects us from unwanted GENERATE statements in particular.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/13626)
If you have a CHOICE type that it must use explicit tagging - otherwise
the template is invalid. We add tests for this.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
It never makes sense for multi-string or CHOICE types to have implicit
tagging. If we have a template that uses the in this way then we
should immediately fail.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
It never makes sense for multi-string or CHOICE types to use implicit
tagging since the content would be ambiguous. It is an error in the
template if this ever happens. If we detect it we should stop parsing.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
If a GENERAL_NAME field contained EdiPartyName data then it was
incorrectly being handled as type "other". This could lead to a
segmentation fault.
Many thanks to David Benjamin from Google for reporting this issue.
CVE-2020-1971
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
EDIPartyName has 2 fields that use a DirectoryString. However they were
marked as implicit tagging - which is not correct for a CHOICE type.
Additionally the partyName field was marked as Optional when, according to
RFC5280 it is not.
Many thanks to github user @filipnavara for reporting this issue. Also to
David Benjamin from Google who independently identified and reported it.
Fixes#6859
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Fixes#10366
The one place that actually used was in the legacy printing of ecparams.
This has been replaced by the pointtobuf variant.
The ecparam app was using one of these functions - this line has just been
removed as another PR will remove all the code generated lines..
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13294)
Move detailed doc to specific new files in doc/man1/openssl-*-options.pod
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/13315)
This also adds the following functions, for completeness:
PEM_write_PrivateKey_ex(), PEM_write_bio_PrivateKey_ex(),
PEM_write_PUBKEY_ex, PEM_write_bio_PUBKEY_ex
Fixes#13542
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13547)
These functions are documented to return 0 if the size they are
supposed to return 0 if the size isn't available. They needed a bit
of adjustment to actually do so, since the backend functions they call
might return negative numbers in that case.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13611)
Without these check, a DSA structure without key parameters will cause
these functions to crash. This is also the case in pre-3.0 OpenSSL,
but since we now extract these data early, to cache them in the
EVP_PKEY structure, the same crash happens earlier and much more
internally.
The added checks are of the same kind as DSA_security_bits() already
does.
Fixes#13610
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13611)
