mbox series

[Openvpn-devel,v2,0/2] Stop failed cipher/digest lookups from polluting the OpenSSL error queue

Message ID 20260928143730.47047-1-drew@linuxkids.com
Headers
Series Stop failed cipher/digest lookups from polluting the OpenSSL error queue |

Message

Drew Blokzyl Sept. 28, 2026, 2:37 p.m. UTC 
  From: Ubuntu <ubuntu@ip-10-241-5-229.remotetesting.secureworks.com>

Root-cause follow-up to the "CRL: cannot read CRL from file" report
(GitHub #1103, PR #1104, Gerrit change 1950 for v1 of patch 1).

Changes in v2:

Patch 1 takes the shape Arne suggested on the PR review: cipher_get()
returns NULL for "none" before touching OpenSSL, no error marks and no
wolfSSL shim, so cipher_valid_reason() keeps finding the OpenSSL reason
on the queue when it reports an unknown cipher (Razvan's point on
Gerrit 1950). The CBC-sibling probe in cipher_kt_block_size() and
md_valid() are left as they are and named in the commit message;
measured on the same rig, the entry the CHACHA20-CBC probe leaves does
not survive to the next client instance.

Patch 2 is unchanged.

Validated again on the aarch64 Ubuntu 26.04 server (OpenSSL 3.5.5,
DCO) with gdb watching the queue: five client instances (UDP, TCP,
CHACHA20-POLY1305, a plain one after it, and one against a garbage CRL)
enter multi_create_instance() and backend_tls_ctx_reload_crl() with an
empty queue, four CRL replacements give four clean reloads, the garbage
CRL still fails with "loaded 0 CRLs" / "VERIFY ERROR: CRL not loaded".

Drew Blokzyl (2):
  Do not look up the "none" cipher in OpenSSL
  Make CRL reload EOF detection independent of stale error queue entries

 src/openvpn/crypto_openssl.c |  9 +++++++++
 src/openvpn/ssl_openssl.c    | 13 +++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)