| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
|
|
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: Tim Hudson <tjh@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23584)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23598)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23598)
|
|
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: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21206)
|
|
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)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23571)
|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23495)
|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23495)
|
|
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: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
Fixes #23199
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23319)
|
|
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)
|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23343)
|
|
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23343)
|
|
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)
|
|
responses
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: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22674)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22674)
|
|
respective -profile option
Also add missing getter functionss OSSL_CMP_{CTX,HDR}_get0_geninfo_ITAVs() to CMP API.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21281)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22981)
|
|
HPE has a weird preference to prefix letters and zero-padding. Properly trim
them before processing.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22891)
|
|
In 160f48941d14 I made L_ENDIAN defined when the system is guessed to be
linux64-loongarch64. Unfortunately now I found it problematic:
1. This should be added into Configurations/10-main.conf, not here.
Having it here causes a different configuration when
linux64-loongarch64 is explicitly specified than guessed.
2. With LTO enabled, this causes many test failures on
linux64-loongarch64 due to #12247.
So I think we should remove it for now (master and 3.2 branch), and
reintroduce it to Configurations/10-main.conf when we finally sort
out #12247.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22812)
|
|
VSI C on OpenVMS for x86_64 has a bit more information than on other
hardware. This is no doubt because it's based on LLVM which leaves an
opening for cross compilation.
VSI C on Itanium:
$ CC/VERSION
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L3
VSI C on x86_64:
$ CC/VERSION
VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22792)
|
|
libabigail is currenly only validating symbol presence and version
information in ci. We should also be validating function parameters,
types, etc. To do this we need to build the library with -g so the
dwarf information is available for libabigail to interrogate
while we're at it, also add a script to re-generate the xml that abidiff
uses for comparison during ci runs, to make updates easier
Fixes #22712
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22713)
|
|
CMake's older package finder, FindOpenSSL.cmake, does a best guess effort
and doesn't always get it right.
By CMake's own documentation, that's what such modules are (best effort
attempts), and package producers are (strongly) encouraged to help out by
producing and installing <PackageName>Config.cmake files to get a more
deterministic configuration.
The resulting OpenSSLConfig.cmake tries to mimic the result from CMake's
FindOpenSSL.cmake, by using the same variable and imported target names.
It also adds a few extra variables of its own, such as:
OPENSSL_MODULES_DIR Indicates the default installation directory
for OpenSSL loadable modules, such as providers.
OPENSSL_RUNTIME_DIR Indicates the default runtime directory, where
for example the openssl program is located.
OPENSSL_PROGRAM Is the full directory-and-filename of the
openssl program.
The imported targets OpenSSL::Crypto and OpenSSL::SSL are as precisely
specified as possible, so for example, they are specified with the both the
import library and the DLL on Windows, which should make life easier on that
platform.
For the moment, one of the following must be done in your CMake project for
this CMake configuration to take priority over CMake's FindOpenSSL.cmake:
- The variable CMAKE_FIND_PACKAGE_PREFER_CONFIG must be set to true prior
to the 'find_package(OpenSSL)' call.
- The 'find_package' call itself must use the "Full Signature". If you
don't know any better, simply add the 'CONFIG' option, i.e. from this
example:
find_package(OpenSSL 3.0 REQUIRED)
to this:
find_package(OpenSSL 3.0 REQUIRED CONFIG)
Just as with the 'pkg-config' exporters, two variants of the .cmake files
are produced:
- Those in 'exporters/' are installed in the location that 'pkg-config'
itself prefers for installed packages.
- Those in the top directory are to be used when it's desirable to build
directly against an OpenSSL build tree.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20878)
|
|
The pkg-config exporters were a special hack, all in
Configurations/unix-Makefile.tmpl, and this was well and good as long
as that was the only main package interface configuration system that we
cared about.
Things have changed, though, so we move the pkg-config production to be
templatable in a more flexible manner. Additional templates for other
interface configuration systems can then be added fairly easily.
Two variants of the .pc files are produced:
- Those in 'exporters/' are installed in the location that 'pkg-config'
itself prefers for installed packages.
- Those in the top directory are to be used when it's desirable to build
directly against an OpenSSL build tree.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20878)
|
|
Also sync libcrypto.num and libssl.num with 3.2 branch and
fix the EVP_DigestSqueeze symbol version.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/22688)
|
|
Fixes #7894
This allows SHAKE to squeeze multiple times with different output sizes.
The existing EVP_DigestFinalXOF() API has been left as a one shot
operation. A similar interface is used by another toolkit.
The low level SHA3_Squeeze() function needed to change slightly so
that it can handle multiple squeezes. This involves changing the
assembler code so that it passes a boolean to indicate whether
the Keccak function should be called on entry.
At the provider level, the squeeze is buffered, so that it only requests
a multiple of the blocksize when SHA3_Squeeze() is called. On the first
call the value is zero, on subsequent calls the value passed is 1.
This PR is derived from the excellent work done by @nmathewson in
https://github.com/openssl/openssl/pull/7921
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21511)
|
|
In testing the quic demos, I found that the quicserver refused to start for me,
indicating an inability to bind a socket to listen on
The problem turned out to be that getaddrinfo on my system was returning
multiple entries, due to the fact that /etc/host maps the localhost host name to
both ipv4 (127.0.0.1) and ipv6 (::1), but returns the latter as an ipv4 mapped
address (specifying family == AF_INET)
It seems like the proper fix would be to modify the /etc/hosts file to not make
that mapping, and indeed that works. However, since several distribution ship
with this setup, it seems like it is worthwhile to manage it in the server code.
its also that some other application may be bound to a given address/port
leading to failure, which I think could be considered erroneous, as any failure
for the full addrinfo list in quicserver would lead to a complete failure
Fix this by modifying the create_dgram_bio function to count the number of
sockets is successfully binds/listens on, skipping any failures, and only exit
the application if the number of bound sockets is zero.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22559)
|
|
We would like to be able to log and audit the symbols we use in openssl
so that we might catch when a new platform symbols is referecned
Add such a script (just on unix platforms for now) that gathers the used
symbols not belonging to libcrypto or libssl, and compare it to a prior
known set of used symbols. Error out if a new symbol is found
Add this script to the ci workflow in CI to capture newly
introduced platform symbols
Fixes #22330
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22478)
|
|
Previously we entered an infinite loop if these things failed.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22557)
|
|
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22405)
|
|
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22247)
|
|
Rather than instantiate the private and primary DRBGs during the
selftest, instead use a test RNG. This leaves the DRBG setup
pristine and permits later replacement of the seed source despite
the very early running power up self tests.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21964)
|
