This function is only useful for EAP-FAST, but was previously undocumented.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24309)
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23768)
Introduce the capability to retrieve and update Certificate Revocation Lists
(CRLs) in the CMP client, as specified in section 4.3.4 of RFC 9483.
To request a CRL update, the CMP client can send a genm message with the
option -infotype crlStatusList. The server will respond with a genp message
containing the updated CRL, using the -infoType id-it-crls. The client can
then save the CRL in a specified file using the -crlout parameter.
Co-authored-by: Rajeev Ranjan <ranjan.rajeev@siemens.com>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23768)
Several of the attribute values defined for use by attribute certificates
use multi-valued data in an ASN.1 SEQUENCE. Allow reading of these values
from a configuration file, similar to how generic X.509 extensions are
handled.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
The IETFAtrrSyntax type is used for the values of several attributes
defined in RFC 5755 for use with attribute certificates.
Specifically this type is used with the "Charging Identity" and
"Group" attributes.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
Add API to manage attribute certificate extensions
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
Add functions to print an attribute certificate. Several
attribute value types defined by the RFC 5755 specification
are multi-field values (i.e ASN1_SEQUENCE rather than an ASN1_STRING
or similar format). Currently those values are printed using
`ASN1_item_print`. A more user-friendly output mechanism (maybe
similar to the i2r_ functions used for X509 extensions) could be
added in future.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
Only fields that are allowed by RFC 5755 are
accessible through this API. Fields that are only supported
in version 1 attribute certificates (e.g. the AttCertIssuer
v1Form fields) are not implemented.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
Add support for attribute certificates (v2) as described
in RFC 5755 profile.
Attribute certificates provide a mechanism to manage authorization
information separately from the identity information provided by
public key certificates.
This initial patch adds the ASN.1 definitions
and I/O API. Accessor functions for the certificate fields
will be added in subsequent patches.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15857)
Create a new hashtable that is more efficient than the existing LHASH_OF
implementation. the new ossl_ht api offers several new features that
improve performance opportunistically
* A more generalized hash function. Currently using fnv1a, provides a
more general hash function, but can still be overridden where needed
* Improved locking and reference counting. This hash table is
internally locked with an RCU lock, and optionally reference counts
elements, allowing for users to not have to create and manage their
own read/write locks
* Lockless operation. The hash table can be configured to operate
locklessly on the read side, improving performance, at the sacrifice
of the ability to grow the hash table or delete elements from it
* A filter function allowing for the retrieval of several elements at a
time matching a given criteria without having to hold a lock
permanently
* a doall_until iterator variant, that allows callers which need to
iterate over the entire hash table until a given condition is met (as
defined by the return value of the iterator callback). This allows
for callers attempting to do expensive cache searches for a small
number of elements to terminate the iteration early, saving cpu cycles
* Dynamic type safety. The hash table provides operations to set and
get data of a specific type without having to define a type at the
instatiation point
* Multiple data type storage. The hash table can store multiple data
types allowing for more flexible usage
* Ubsan safety. Because the API deals with concrete single types
(HT_KEY and HT_VALUE), leaving specific type casting to the call
recipient with dynamic type validation, this implementation is safe
from the ubsan undefined behavior warnings that require additional
thunking on callbacks.
Testing of this new hashtable with an equivalent hash function, I can
observe approximately a 6% performance improvement in the lhash_test
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23671)
Generally we can get away with just using CRYPTO_atomic_load to do
stores by reversing the source and target variables, but doing so
creates a problem for the thread sanitizer as CRYPTO_atomic_load hard
codes an __ATOMIC_ACQUIRE constraint, which confuses tsan into thinking
that loads and stores aren't properly ordered, leading to RAW/WAR
hazzards getting reported. Instead create a CRYPTO_atomic_store api
that is identical to the load variant, save for the fact that the value
is a unit64_t rather than a pointer that gets stored using an
__ATOMIC_RELEASE constraint, satisfying tsan.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23671)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)
Change introduces a default limit on HTTP headers we expect to receive
from server to 256. If limit is exceeded http client library indicates
HTTP_R_RESPONSE_TOO_MANY_HDRLINES error. Application can use
OSSL_HTTP_REQ_CTX_set_max_response_hdr_lines() to change default.
Setting limit to 0 implies no limit (current behavior).
Fixes#22264
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23781)
times.
Fixes#23672
There are many name/value pairs currently that have duplicate names e.g.
'CAPABILITY_TLS_GROUP_MAX_TLS' => "tls-max-tls",
'CAPABILITY_TLS_SIGALG_MAX_TLS' => "tls-max-tls",
Stripping the .pm file down to just the above entries and running
multiple times gives different results for the produce_decoder.
On multiple runs any iterations over the unordered hash table keys using
foreach my $name (keys %params) results in a different order on multiple
runs. Because of this the mapping from the hash 'value' back to the
'key' will be different.
Note that the code also uses another mechanism in places that uses
"name1" => "value"
"name2" => "*name1"
Rather than fix all the strings the change done was to sort the keys. If
we were to chose to fix the strings then the perl code should be changed
to detect duplicates.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/23688)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21660)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23535)
We use isnan() and isinf() in JSON_ENC now, which is translated to a
call to Microsoft's standard library function _dclass.
.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23517)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23360)
This builds shared libraries as libxxx.so, libxxx.so.ver and static
libraries as libxxx.a. For shlib_variant builds, it builds libxxx.so,
libxxxvariant.so.ver, and libxxxx.a. libxxx.so is a linker import
library that directs the linker to embed a run-time dependency
reference to libxxxvariant.so.ver. Only libxxxvariant.so.ver is needed
at runtime.
Fixes#21518
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21540)
Android is enabling support for the riscv64 ISA. Add a configuration
option to support building for it, aligned with the existing
linux-riscv64 configuration.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/23427)
ubsan on clang17 has started warning about the following undefined
behavior:
crypto/lhash/lhash.c:299:12: runtime error: call to function err_string_data_hash through pointer to incorrect function type 'unsigned long (*)(const void *)'
[...]/crypto/err/err.c:184: note: err_string_data_hash defined here
#0 0x7fa569e3a434 in getrn [...]/crypto/lhash/lhash.c:299:12
#1 0x7fa569e39a46 in OPENSSL_LH_insert [...]/crypto/lhash/lhash.c:119:10
#2 0x7fa569d866ee in err_load_strings [...]/crypto/err/err.c:280:15
[...]
The issue occurs because, the generic hash functions (OPENSSL_LH_*) will
occasionaly call back to the type specific registered functions for hash
generation/comparison/free/etc, using functions of the (example)
prototype:
[return value] <hash|cmp|free> (void *, [void *], ...)
While the functions implementing hash|cmp|free|etc are defined as
[return value] <fnname> (TYPE *, [TYPE *], ...)
The compiler, not knowing the type signature of the function pointed to
by the implementation, performs no type conversion on the function
arguments
While the C language specification allows for pointers to data of one
type to be converted to pointers of another type, it does not
allow for pointers to functions with one signature to be called
while pointing to functions of another signature. Compilers often allow
this behavior, but strictly speaking it results in undefined behavior
As such, ubsan warns us about this issue
This is an potential fix for the issue, implemented using, in effect,
thunking macros. For each hash type, an additional set of wrapper
funtions is created (currently for compare and hash, but more will be
added for free/doall/etc). The corresponding thunking macros for each
type cases the actuall corresponding callback to a function pointer of
the proper type, and then calls that with the parameters appropriately
cast, avoiding the ubsan warning
This approach is adventageous as it maintains a level of type safety,
but comes at the cost of having to implement several additional
functions per hash table type.
Related to #22896
Reviewed-by: Sasa Nedvedicky <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23192)
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
It would be helpful to be able to generate RSA's dmp1/dmq1/iqmp values
when not provided in the param list to EVP_PKEY_fromdata. Augment the
provider in ossl_rsa_fromdata to preform this generation iff:
a) At least p q n e and e are provided
b) the new parameter OSSL_PARAM_RSA_DERIVE_PQ is set to 1
Fixes#21826
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21875)
Partial fix for #8026
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22656)
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23149)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/20727)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/20727)
