os-check builds a wolfSSL with neither, then wolfssh against it, so the
Ed25519-only paths are exercised. That wolfSSL line names two things the
short option list does not imply: --enable-ed25519-stream, which wolfSSH
needs to keep Ed25519, and --enable-base64encode, which the ssh client
app needs and which defaults off away from x86_64.
The merge step takes --failure-mode=all, so a raw profile left short by
a killed process is warned about and skipped instead of aborting the
report. Tests SIGKILL their servers in cleanup traps, and a process
killed while writing its profile leaves a corrupt header behind. The
step still fails when no profile can be read at all.
Every run of this job rebuilt wolfSSL --enable-all from source on a
Windows runner, about five minutes, even though the ref is pinned
and the configure flags never change between runs.
Add an actions/cache step keyed on wolfssl-mingw-regress-wolfssl-
<ref>-windows-latest, matching the naming singlethread-check.yml and
x509-interop.yml use. Those two split the work into a build_wolfssl
job and a build_wolfssh job, with a lookup-only cache check in the
first and a fail-on-cache-miss restore in the second. This job has
no such split, so it uses a single plain actions/cache step instead:
it restores on a hit and saves automatically after the job on a
miss.
The MSYS2 shell's $HOME lives under setup-msys2's own temp install
directory, not a path stable across runner images, so build to
${{ github.workspace }}/wolfssl-install instead: actions/cache
resolves a relative path against GITHUB_WORKSPACE, and cygpath -u
gives the msys2 shell steps the same directory as $WOLFSSL_INSTALL.
The wolfssl checkout in mingw-regress had no ref, so it always built
against wolfssl/wolfssl's default branch. An upstream change there
could break this job with nothing changed on the wolfssh side to
explain it, and this job in particular turned out to be sensitive to
exact wolfSSL build details while it was being brought up.
Pin it to v5.9.1-stable, the same tag singlethread-check.yml and
x509-interop.yml already use, confirmed to include wc_mlkem.c so the
ML-KEM coverage this job exercises is still built. The build and
asan-tests jobs in this file have the same unpinned checkout but are
left alone here, since they were not touched by this change.
The new run showed the ws2_32/crypt32 link fix worked (configure
passed) but make then failed: "No rule to make target
'tests/regress.test'." Reproducing the autotools build locally
confirmed why: MinGW's EXEEXT is ".exe", so automake's check_PROGRAMS
rule names the binaries tests/regress.test.exe and tests/unit.test.exe,
not the extension-less names this job was asking make to build and run.
config.log from a failing run showed the wolfCrypt_Init AC_CHECK_LIB
probe pulling in ssl.c/internal.c/wolfio.c from the static
libwolfssl.a, leaving Winsock (socket, send, recv, inet_pton, ...) and
cert store (CertOpenSystemStoreA, ...) symbols unresolved. A shared
build would defer that resolution to the DLL; the static archive here
needs ws2_32 and crypt32 passed explicitly via LIBS.
The mingw-regress job's wolfssh configure step fails with
"libwolfssl is required for wolfssh" even though libwolfssl.a is
installed at the expected path. AC_CHECK_LIB only reports pass/fail;
dump config.log on failure to see the actual link error.
The Windows StartSSHD() path rebuilds argv from GetCommandLineW(). A
regression there left -D foreground mode walking the raw wide command
line, so -f and -p were ignored and the daemon used its built-in
defaults. Nothing in CI caught that.
Add sshd_dash_d_test.ps1: it starts wolfsshd with -D and a config file
at a non-default path whose Port line differs from the -p value, then
checks the listener binds the -p port and not the config port. That
holds only when -D mode parsed both -f and -p. Run it from the Windows
build job next to the existing LoginGraceTime check.
tests/regress.c holds the only coverage for the Windows SFTP open path,
including TestSftpWindowsOpenFlagMatrix, which walks the RecvOpen
CREAT/EXCL/TRUNC/APPEND matrix against the CreateFile() disposition
table. That test is guarded by USE_WINDOWS_API and ran in no CI job. The
MSVC solution in ide/winvs has no regress project, and regress.c does not
build with cl because it includes arpa/inet.h and unistd.h, so the
disposition fix it locks down could regress unnoticed.
Add an MSYS2 MinGW64 job to the Windows workflow. MinGW defines _WIN32,
so wolfssh/settings.h turns on USE_WINDOWS_API and the Windows-only
branches compile and run. The job builds wolfSSL static, configures
wolfSSH with --enable-sftp, and runs tests/regress.test and
tests/unit.test. wolfsshd is left out: its autotools path is not
MinGW-clean and the MSVC solution already covers it.
- _GetHomeDirectory loads the user's profile when WOLFSSHD_AUTH's new
profile member is NULL, setting PROFILEINFO.dwSize first and keeping
the returned hProfile there.
- _GetProfileDirectory reads the home directory with
GetUserProfileDirectoryW, in place of SHGetKnownFolderPath and the
%USERPROFILE% expansion. CheckPublicKeyWIN calls it directly, so a
caller that has not authenticated the user builds no profile.
- wolfSSHD_AuthCloseToken unloads the profile before closing the token,
calling RegCloseKey when the unload fails.
- The Windows shell cleanup calls RevertToSelf() before closing the auth
token rather than after.
- windows-sftp.yml gains a no_profile job that covers an exec session,
two overlapping sessions, and SFTP for users created with net user
alone; it skips the earlier SFTP step so its exec session connects
first.
- Both Windows workflows log testuser on once so Windows builds a real
profile, in place of writing the home directory and ProfileList entry
by hand, and the recursive icacls grants on it are gone.
Issue: F-13326
- windows-sftp.yml generates an ecdsa key for testuser, authorizes it,
and builds a source tree holding two files, a nested subdirectory
and an empty one.
- A new step pulls that tree with scp -O -r and fails unless every
file and directory arrives. -O keeps OpenSSH on the legacy SCP
protocol rather than SFTP.
- The header comment lists the recursive SCP scenario.
enable SHA1 with windows cert store test case
expand test cases, adjust to authorized key file, minor dead code adjustments
add more documentation, refactor duplicate code sections, clean up test cases, more adjustments to logging spamming protections
add Windows cert store test case
make windows cert feature default disabled and simplify macro guard
additional unit tests, advertise x509 and pubkey, use CN to match username, build check for WOLFSSL_SYS_CA_CERTS, fix for CM ref count
additional build test, uniform enum name, fail on unkown cert store ecc curve, tie in of loading whole cert store for sys CA's
Gates ML-DSA composites behind WOLFSSH_NO_MLDSA_COMPOSITES.
Deduplicates key handling and uses heap allocation for
composite buffers when compiling for small stacks.
The dependency assertion checked only that wolfssl was present with a
DEPENDS_ON edge, never that the recorded version matched WOLFSSL_DIR, so
the SBOM could attest a version wolfSSH was not built against and still
pass. Compare versionInfo against the tree.
That assertion alone would not have caught it: the runner installs
wolfssl from the same tree it passes as WOLFSSL_DIR, so pkg-config and
wolfssl/version.h always agree and a wrong source is indistinguishable
from a right one. Add a step that forces them apart -- a stub pkg-config
reports a sentinel version, and a distclean'd copy of the tree has no
generated version.h, so the configure.ac fallback is the only route to a
correct answer. Reverting the recipe fix makes this step fail with the
sentinel, and the fallback path now has CI coverage it lacked.
The gate skipped SBOM generation and exited 0 whenever wolfssl's
scripts/gen-sbom was absent, so the job could report success having
never exercised `make sbom`. That was deliberate while the script was
unmerged, but it landed on master in wolfSSL/wolfssl#10343.
On master, a missing gen-sbom or one too old for --dep-wolfssl is a
regression, so fail instead of skipping: a green run now always means
the target was exercised and the wolfssl-dependency assertions ran.
Only a deliberately pinned older wolfssl_ref still degrades to a skip.
The ref is passed through env rather than interpolated into the shell
script, to keep the workflow expression out of the command line.
wolfSSL/wolfssl#10343 merged on 2026-07-27, but the SBOM workflow still
checked out wolfssl at refs/pull/10343/head. GitHub keeps PR refs alive
after merge, so CI stayed green while validating a pre-merge snapshot
rather than master. Point wolfssl_ref and its fallback at master.
Distinguish the two gen-sbom lookup failures. A set-but-wrong
WOLFSSL_DIR previously printed the "re-run with WOLFSSL_DIR=..." advice
to someone who had already set it; it now names the path that was
probed and states that WOLFSSL_DIR is a source tree, not an install
prefix.
Refresh the README and in-recipe notes that still told users to track
the #10343 branch until it merged.
Re-sync scripts/sbom.am with the canonical wolfSSL copy ($(docdir)
sbomdir, [[:space:]] version parse, GNU-make and uninstall-sbom docs)
and widen the SBOM workflow pull_request filter to '**'.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Move the make sbom / install-sbom / uninstall-sbom recipe out of
Makefile.am into a reusable scripts/sbom.am fragment; Makefile.am now
just declares the product facts (name, LICENSING, wolfssl dependency,
GPL-3.0-only default) and includes it.
Add a GitHub Actions workflow covering both SBOM paths:
- autotools: build wolfSSL + wolfSSH, run make sbom, assert SPDX
validity, CycloneDX identity, reproducibility, and the wolfssl
dependency edge.
- embedded: run gen-sbom against user_settings.h (via pcpp) + the
wolfSSH source set, asserting the same identity/validity/reproducibility
plus that user_settings.h options and the wolfssl dependency are
captured.
Both gracefully skip on a gen-sbom that predates the wolfSSL SBOM
change.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
- --enable-sshclient defaults to no, so the app was built only by the
configs that use --enable-all, and never under the multi-compiler
warning flags. Add it to the multi-compiler matrix.
- Add scripts/sshclient.test, run by make check. It covers the client's
sessions and the -E log file against the echoserver.
- The script is not gated on BUILD_SSHCLIENT. It exits 77 when the
client app or the echoserver isn't there, so every build runs it and
the ones without the app report it as a skip.
- Check the client and the echoserver by asking each for its usage
message, not by looking for the file. Both are libtool wrapper
scripts in the build tree, and a wrapper outlives a reconfigure that
drops the program it wraps, then runs only far enough to say so.
- The echoserver runs in echo mode and the client's stdin comes from a
fifo written a piece at a time, so the session carries data and ends
on its own. Each client run has a watchdog.
- Rename sshd-test.yml's job to cover both apps. That workflow builds
the client app along with wolfsshd.
- Check that the command reaches the server, now that the client sends
it rather than discarding it.
- Make the SINGLE_THREADED guard a preprocessor #error. The runtime
err_sys() only caught the misconfiguration in an autotools build that
got as far as running; the #error catches it at compile time for the
IDE and plain Makefile builds too.
- Treat WS_WANT_READ and WS_WANT_WRITE out of wolfSSH_worker() as a
clean shutdown. The socket is non-blocking, so the peer having
nothing ready is not a session failure.
- No job compiled a wolfSSH test binary with WOLFSSH_TPM defined, so a
test guarded on it compiled out everywhere and could not gate a
merge. This job enables TPM but only builds; the jobs that run make
check do not enable it.
- Add a make check step. automake's check-am builds every check_PROGRAM
regardless of the TESTS override, so this is the only job that
compiles wolfSSH's tests with TPM support.
- Override TESTS to run only tests/api.test, the one suite with
TPM-specific tests. kex.test also aborts in the example client, which
demands -K in a TPM build.
- Restrict it to one matrix cell. The 2x2x2 matrix varies the simulator
and the host key, neither of which these tests touch.
- Assert -DWOLFSSH_TPM in AM_CPPFLAGS first. A build without it
compiles the guarded tests out and still exits 0, a hollow pass.
- Dump tests/api.log on failure and archive it.
- add a v4.4.0 matrix leg alongside v3.4.0
- run each leg in the Zephyr CI image with the matching SDK
(ci:v0.26.4/SDK 0.16.1, ci:v0.29.0/SDK 1.0.0); drops the manual
deps, west, pip and SDK install steps
- scope twister by --testsuite-root and drop --test: the scenario
id is path-prefixed on 3.4.0 but bare on 4.x
- replace zip with tar caf logs.tar.xz for the failure-log artifact
1. Update WOLFSSL_REF to v5.9.1-stable in the ML-KEM and single-thread
tests (interop-mlkem.yml, singlethread-check.yml).
2. Drop kyber.yml; its coverage is a strict subset of interop-mlkem.yml.
Fold its push and workflow_dispatch triggers into interop-mlkem.yml so
ML-KEM still runs on master/release pushes and via manual dispatch.
3. Drop liboqs from the ML-KEM test. It isn't in configure.ac any more.
John Safranek
Hideki Miyazaki
Yosuke Shimizu
JacobBarthelmeh
Emma Stensland
Mark Atwood
Sameeh Jubran
Paul Adelsbach
aidan garske