This is _technically_ a semver violation, but in practice it's already unsafe on all other platforms, and is unsound otherwise.

Sometimes the network is cursed and it takes forever. In these cases it's better to fail quickly and retry it.

Previously, passing `iv: None` to a cipher that requires an IV (CBC,
GCM, CTR, etc.) silently passed a null pointer to OpenSSL, which used
an all-zero IV. This matched neither the documented contract ("Panics
if an IV is required by the cipher but not provided") nor safe
cryptographic practice.

Add an assertion that enforces the documented behavior, and add tests
for both CBC and GCM to verify the panic.

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>

* Add initial support for OpenSSL 4.x betas

Accept OpenSSL 4.x in the version check (raising the ceiling to 4.0.0
final), add the ossl400 cfg flag, and ignore tests with behavioral
changes in OpenSSL 4 (tmp_dh_callback, zero_length_buffers).

* Fix zero-length SSL_read_ex/SSL_write_ex calling into OpenSSL

The empty-buffer early return was only on the pre-1.1.1 code path.
On the ossl111/libressl path, SSL_read_ex and SSL_write_ex were called
with length 0, causing OpenSSL to perform wire I/O unnecessarily. This
was exposed by OpenSSL 4 which now errors. Hoist the guard above the
cfg_if so it applies to all versions.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Handle const-qualified return types in OpenSSL 4

OpenSSL 4 changed X509_NAME_ENTRY_get_data, X509_NAME_ENTRY_get_object,
and X509_CRL_get_issuer to return const pointers. Use const_ptr_if(ossl400)
in the FFI bindings and cast to *mut at the call sites since we only
return immutable references.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Add Version::Openssl4xx, bind SSL_OP_IGNORE_UNEXPECTED_EOF

Add a distinct Openssl4xx variant to the Version enum and use it for
OpenSSL 4.x detection. Bind SSL_OP_IGNORE_UNEXPECTED_EOF (gated on
ossl400) and set it in the default_verify_paths test to handle peers
that close without close_notify.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Add 4.0.0-beta1 in CI

* cargo fmt

* update a comment and some cfg guards

* missed a comment

* 4.0.0

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>

Clamp to maximum buffer size and indicate the truncation with
trailing dots.

* Fix dangling stack pointer in custom extension add callback

The out pointer given to OpenSSL was captured before the buffer was
moved into ex_data. For inline-storage types like [u8; N], as_ptr()
points into the value itself, so the move invalidated the pointer.
Capture it from the final heap location instead.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

* Update openssl/src/ssl/callbacks.rs

Co-authored-by: Theo Buehler <[email protected]>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
Co-authored-by: Theo Buehler <[email protected]>

The 4.3.0 and 4.3.1 releases are dev releases for testing and the
definite stable release will be in about a month.

There will be no API and ABI changes on 4.3.x, so allow it.

https://marc.info/?l=libressl&m=177656691217255&w=2

* fix inverted bounds assertion in AES key unwrap

This also adds several additional test cases in addition to checking the
buffer lengths

* fix formatting

)

The invoke_passwd_cb trampoline passed the user closure's returned usize
straight to OpenSSL as the password length, without checking it against
the size of the scratch buffer it handed out. A safe Rust callback that
returned a value larger than buf.len() (for example, the length of an
external secret rather than the number of bytes written) caused
EVP_BytesToKey to read past the buffer during key derivation on OpenSSL
1.1 and LibreSSL, leaking adjacent stack bytes into the derived key.

Now treat an oversized return as a callback error (return 0 to OpenSSL),
matching the existing behavior when the closure returns Err.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

The PSK and cookie-generate FFI trampolines forwarded the user closure's
returned usize to OpenSSL without checking it against the bounded slice
handed to the closure. A safe Rust callback returning an oversize value
could make OpenSSL read past the end of the cookie/PSK buffer and
serialise those bytes into the HelloVerifyRequest / TLS PSK exchange,
leaking adjacent memory to the network peer.

Clamp the returned length to the slice length in raw_client_psk,
raw_server_psk, raw_stateless_cookie_generate, and raw_cookie_generate;
on overflow the trampoline now reports failure to OpenSSL instead of
forwarding the bogus length.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

If a caller passes an output buffer that is shorter than the digest
size, digest_final() would write past its end, usually corrupting
the stack. This is reachable from safe rust.

Check the size and return an error if it is too small.

* Check derive output buffer length on OpenSSL 1.1.x

On OpenSSL 1.1.x the X25519, X448, and HKDF-extract pmeths ignore the
incoming `*keylen` and unconditionally write the full shared secret
(32/56/hashLen bytes), and their `EVP_PKEY_METHOD` structs do not set
`EVP_PKEY_FLAG_AUTOARGLEN`, so `EVP_PKEY_derive` does not check either.
A caller that passed a `&mut [u8]` shorter than the natural output size
would get a write past the buffer from safe Rust.

On 3.0+, the provider implementations check the size themselves, so
the cfg-gated pre-check only applies on 1.1.x. `usize::MAX` is a
sentinel for caller-chosen output length (HKDF expand modes) where the
pmeth honors `*keylen` and no check is needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

* Also apply fix on LibreSSL

* Tolerate NULL-out probe failures in PkeyCtx::derive on OpenSSL 1.1.x

The length pre-check introduced in 713a2a2 calls `EVP_PKEY_derive` with
a NULL output buffer to discover the required size. Some pmeths (notably
HKDF in extract-and-expand and expand-only modes on OpenSSL 1.1.x) don't
handle a NULL output and fail the probe with an empty error stack,
making the HKDF tests fail with `ErrorStack([])`.

Those modes honor `*keylen` during derivation, so the probe isn't needed
for safety there. When the probe fails, clear any OpenSSL errors it may
have left and proceed to the real derive call. The safety check still
fires for X25519/X448/HKDF-extract, which do support the probe.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

* Gate derive_undersized_buffer_returns_error tests on X25519 availability

`PKey::generate_x25519` is only available on `any(ossl111, boringssl,
libressl370, awslc)`, so the undersized-buffer tests don't compile
against OpenSSL 1.1.0. Match the cfg on the tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

* Truncate into a temp buffer when derive output exceeds caller's buffer

The pre-check introduced in 713a2a2 returned `Err` when the probed
natural output size exceeded the caller's buffer. That protected
X25519/X448/HKDF-extract from OOB writes on 1.1.x, but broke the
default ECDH pmeth, which deliberately truncates when `*keylen` is
smaller than the natural shared-secret size (OpenSSL documents this as
intended behavior in `crypto/ec/ec_pmeth.c`).

Instead, when the probe reports a natural size larger than the caller's
buffer, derive into a `Vec<u8>` of the probed size and copy the leading
bytes out. This prevents the OOB for pmeths that ignore `*keylen`
(X25519/X448/HKDF-extract) and yields the same bytes as a direct call
for pmeths that honor it by truncating (default ECDH), since
`ECDH_compute_key` copies leading bytes of the shared secret either
way. The probe-fails path (HKDF extract-and-expand / expand-only) is
unchanged.

3.0+ providers reject undersized buffers themselves, so the fallback
stays cfg-gated to 1.1.x and LibreSSL.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>