* Stop multi-msg-record depending on the peer's session ticket support
scripts/multi-msg-record.test fails all eleven of its TLS 1.2 cases on any
machine running tlslite-ng 0.8.0-beta1, whenever wolfSSL is built with
session tickets. The wolfSSL client aborts the handshake with
SESSION_TICKET_EXPECT_E (-390).
That beta echoes an empty session_ticket extension in its ServerHello and
sets send_session_ticket unconditionally, then sends no NewSessionTicket
because its default HandshakeSettings carry no ticket keys. Rejecting that
is correct behaviour on our side, per RFC 5077. Upstream fixed the server
in 0.8.0-beta2 by gating the echo on ticket_count and ticketKeys, so only
that one release is affected.
HAVE_SESSION_TICKET alone decides it. A PRB-dtls run on the affected node
makes that plain: three configurations, one commit, one box, and only the
third, --enable-dtls --enable-dtls13 --enable-dtls-mtu
--enable-session-ticket, failed. It is not specific to --enable-all, which
merely happens to turn the feature on.
Hide the extension from the tlslite server for the duration of the TLS 1.2
case, using the monkey patch the test already installs. Session tickets are
not what this test covers, and releases from 0.8.0-beta2 on never echo the
extension here anyway, so this changes nothing on a current tlslite-ng.
Also report the wolfSSL client's return code and stderr on failure. Both
runners preferred the server side traceback and dropped the client's output
entirely, so a failing CI log showed a bare TLSAbruptCloseError from the
socket layer and no sign of the -390 that caused it.
Verified on master and on the failing branch, x86_64 Linux and macOS arm64,
against tlslite-ng 0.8.0-beta1 and 0.8.2: 15 passed, 0 failed, 1 skipped in
every combination. Before the change, 0.8.0-beta1 gives 4 passed, 11 failed.
* Test that a promised but absent session ticket is rejected
RFC 5077 requires a server that puts the session_ticket extension in its
ServerHello to follow with a NewSessionTicket. wolfSSL answers a server
that skips it with SESSION_TICKET_EXPECT_E, but nothing tested that. The
behaviour only came to light because a tlslite-ng beta got it wrong, and a
refactor could relax it into accepting the ticketless handshake without any
test noticing.
Drive the case deliberately: configure the tlslite server with ticket keys
so it promises a ticket on every release, replace _serverSendTickets with
an empty generator so it sends none, and require the client to fail with
-390.
The case skips itself when the client offers no session_ticket extension,
which is how a build without HAVE_SESSION_TICKET reports.
Checked both ways round. Leaving _serverSendTickets intact makes the
handshake succeed and the case fail, so the assertion is specific to the
missing ticket and not to any handshake error. Hiding the extension from
the server, which is how a build without HAVE_SESSION_TICKET looks, makes
the case skip rather than fail.
* Pin tlslite-ng in the os-check workflow
scripts/multi-msg-record.test speaks TLS to a tlslite-ng server, so that
package decides what the 24 --enable-all entries in os-check-linux.json
and the macOS entry are tested against, and whether the test runs at all
rather than reporting SKIP. Installing it unpinned means any upstream
release lands across the whole matrix at once, on whichever unrelated PR
happens to run next.
Pin it to 0.8.2, matching how advisory.yml and sbom.yml pin their Python
dependencies. No behaviour change today: 0.8.2 is what an unpinned install
already resolves to.
Fix guard around inclunde of chacha20_poly1305.h in internal.h for when
session ticket is not ChaCha20-Poly1305.
Fix port allocation and readiness testing in scripts.
Fix other issues in the scripts as well.
Update test.h code around ready file.
For LTO compiles, all functions must be used.
Make sure the assembly functions are marked as 'used' when not called
internally.
Fix a race in the example client that intermittently failed
scripts/unit.test on TLS 1.3 non-blocking session resumption.
RISC-V 64-bit: s0 needed but functions need to omit frame pointer.
Have source matching generated code again.
Replace the one-runner-per-configuration matrices across the
make-check workflow family with a generic pooled runner,
.github/scripts/parallel-make-check.py. Each workflow keeps its
configuration list as JSON next to the invocation; one runner (or a
small fixed set of shards, balanced by measured per-config minutes)
builds every config in its own out-of-tree (VPATH) build directory off
a single checkout/autogen, on a pool of one-per-CPU worker threads,
longest first. Concurrent checks are isolated with bubblewrap network
namespaces, compilations are cached with ccache, the first failure
aborts the rest (fail-fast, with --no-fail-fast to run everything),
and per-config timings plus pool efficiency land in the step summary.
Failure logs upload as artifacts. smoke-test.yml is likewise reworked
into a single pooled job that runs its nine configs on one runner.
Converted workflows (runner jobs per full pass):
os-check.yml 101 -> 8 (92 Ubuntu configs -> 4 shards;
the macOS matrix, the user-settings jobs and
the standalone
macos-apple-native-cert-validation.yml fold
into one macOS runner; Windows unchanged)
pq-all.yml 21 -> 2 shards
disable-pk-algs.yml 15 -> 1
wolfCrypt-Wconversion.yml 11 -> 1
trackmemory.yml 7 -> 1
cryptocb-only.yml 8 -> 1 (incl. the two new SHA512 entries)
multi-compiler.yml 6 -> 1
smallStackSize.yml 6 -> 1
multi-arch.yml 6 -> 1
async.yml 5 -> 1
psk.yml 5 -> 1
no-malloc.yml 3 -> 1
wolfsm.yml 3 -> 1
opensslcoexist.yml 2 -> 1
Measured against current upstream passing runs (job execution time,
queue excluded): ~200 runner jobs / ~374 runner-minutes per full pass
become 23 jobs / ~168 runner-minutes, with more coverage than before.
multi-arch's old matrix combined an "include" list of four
architectures with an "opts" axis; GitHub's include-merge rules made
each arch entry overwrite the previous one, so only the armel
combinations actually ran. The pooled list restores the intended
aarch64/armhf/riscv64 coverage (23 combinations; riscv64 x sp-math is
omitted as invalid - configure rejects sp-math without SP, and
--enable-riscv-asm, unlike --enable-sp-asm, does not bring SP in).
Out-of-tree build fixes this depends on:
- Makefile.am: symlink the read-only test data (certs/, tests/ config
files, sniffer captures and helpers, examples/crypto_policies,
input, quit) into the build tree via a BUILT_SOURCES stamp, removed
again in distclean-local. ChangeToWolfRoot() and the script tests
resolve everything relative to the working directory, so out-of-tree
make check and make distcheck now pass.
- scripts/multi-msg-record.py: locate the client binary from the build
tree working directory rather than the script's source directory.
- configure.ac + wolfssl/include.am: run
support/gen-debug-trace-error-codes.sh from $srcdir; it reads the
error-code headers from the source tree and generates into the build
tree.
- tests/swdev: a WOLFBUILD variable points the sub-make at the build
tree for the configure-generated headers (wolfssl/options.h,
wolfssl/version.h); the in-tree-only guards are dropped.
Portions of PR #10649 are incorporated: the cross-platform
ccache-setup composite action, repository_owner gates on check-headers
and check-source-text, the docs-only paths-ignore on os-check, and the
libspdm timeout bumps.
The test certs are RSA; if NO_RSA is defined the client can neither
load nor verify them. Detect "RSA not supported" in client -? help
and exit 77 (SKIP) before tlslite-ng tries to use the RSA chain.
multi-msg-record.py: auto-detect the CA cert format the wolfSSL client
build accepts (PEM or DER) from the default shown in client -? help.
OPENSSL_EXTRA-style builds need PEM; NO_CODING builds need DER.
ocsp-stapling.test: skip the external login.live.com connection unless
WOLFSSL_EXTERNAL_TEST is explicitly enabled (matches external.test /
google.test convention). Local OCSP tests still run.
ocsp-responder-openssl-interop.test: use ${TMPDIR:-/tmp} for mktemp
templates so the test works when /tmp is not writable.
wolfSSL builds configured with --enable-coding=no cannot parse PEM
because base64 decoding is disabled. Switch the example client's -A
argument to ca-cert.der so the test works in both PEM-enabled and
PEM-disabled builds.
