Added more test vectors as well as locking in behavior of VerifyProtoId
Added round trip test for proto id
Comment fixes
New define for proto id min size
wolfSSH_CTX_SetSshProtoIdStr() now rejects a string that is not
CRLF-terminated, exceeds 255 bytes counting the terminator, or
carries a CR or LF in the body. DoKexInit() subtracts the two
terminator bytes from the length when hashing it, so an
unterminated string underflowed the hash length.
Issue: F-10571
partial progress
- _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.
- WS_FindNextFileA_ex() takes a lastError out-parameter and carries
the body of WS_FindNextFileA(), which now calls it with NULL. A
failing return reports the FindNextFileW() error, or
ERROR_NO_UNICODE_TRANSLATION when the name would not convert.
- FindNextDirEntry() calls WS_FindNextFileA_ex() on Windows. An
ERROR_NO_MORE_FILES result frees ctx->entry, sets it to NULL and
returns WS_NEXT_ERROR so the caller pops the directory; every other
error still returns WS_FATAL_ERROR.
Issue: F-13316
wolfSSH_AGENT_ChannelOpen() settles its channel and agent on whether
the open reached the peer, which SendPacketDelivered() answers from the
flush count. The highwater callback runs after the last byte is out, so
its failure arrives as this send's return, and the rollback read that
as a send that never left.
- give SendPacketDelivered() external linkage, contract in internal.h
- note in agent.h that an error raised once the open is on the wire
leaves the channel open
- test a failing highwater callback: the channel and the agent stand,
and the poll after it is the idempotent one
wolfSSH_AGENT_ChannelOpen() answers a poll on a session that is over
with WS_FATAL_ERROR and WS_DISCONNECT in ssh->error, the shape every
other public sender uses: no channel opened, nothing on the wire,
RFC 4253 section 11.1. wolfSSH_accept() gates the open it drives, so
the new public entry point is the only way in.
- promote SendAfterDisconnect() to WOLFSSH_LOCAL so agent.c uses the
same helper as every other public sender
- leave an open queued before the disconnect unflushed, the rule
wolfSSH_shutdown() applies to all but its own disconnect
- keep WS_DISCONNECT in ssh->error at the accept() call site, which
used to overwrite it with the status the open returns
The one server-side site that opens auth-agent@openssh.com sits inside
wolfSSH_accept(), so an application driving its own channels cannot
reach it: the session records the request and no channel follows.
- add wolfSSH_AGENT_ChannelOpen(), the same open lifted out of accept(),
which still calls it
- it reports WS_BAD_ARGUMENT until the peer asks and on a client
session, and is idempotent after, so an application can poll it
- publish the agent on a queued open too, so a retry after WS_WANT_WRITE
finds it rather than opening a second channel and leaking the first
- flush what is left of a queued open on the next call, rather than
reporting a success the peer never saw
- record ssh->error from the send alone, so neither a poll ahead of the
request nor a failed allocation stops accept() continuing
wolfSSH_SCP_accept() reported any want held in ssh->error in place of
the DoScpRequest() result. A short send that SendChannelData() accepts
leaves WS_WANT_WRITE there with nothing clearing it on a later flush,
so a terminal result came back as retryable and the retry re-entered
the state machine, re-sending an abort confirmation or reading past a
bad message.
- Substitute the want only when the result is WS_FATAL_ERROR and the
want is WS_WANT_READ, the one case GetInputData() hides by value.
- Leave write wants alone; the SCP state machine already returns them.
An application that binds an "scp ..." command to a channel itself has no
way to run the transfer; wolfSSH_accept() did it through a WS_SCP_INIT
re-entry only that state machine can drive.
- add wolfSSH_SCP_accept(), a wrapper over DoScpRequest() reporting
WS_SCP_COMPLETE for any non-negative result, as accept() does
- a receive-side want reaches the wrapper as a generic error with the
want in ssh->error, so report the want itself and let the caller retry
- state that resume contract beside the prototype, and clear a stale want
on entry the way the other re-entrant entry points do
wolfSSH_CTX_SetChannelOpenRespCb() had no caller anywhere in the tree, so
the confirm and fail hooks had no worked example and a forwarding client
had nothing to say which of its opens the peer refused.
- register both arms and print the channel each one names
- name our own id, not the peer's: a refused open never learns the peer's,
and it is the id portfwd_worker() already tracks
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
WOLFSSH_FWD_LOCAL_CLEANUP now fires, and what must not fire matters as
much as what must: the gate is the channel's own setup record, not its
type.
- a peer-opened direct-tcpip channel reports SETUP, CHANNEL_ID, then
CLEANUP when it closes
- a forwarding channel this side opened reports no cleanup, and a
session channel no forwarding action at all
- an open that fails after a successful setup still reports the cleanup,
and a setup that reported failure draws none
- freeing the session, or the channel with wolfSSH_ChannelFree(),
reports it, and the session free after a channel free does not
report it again
The LOCAL_CLEANUP handler closes the target socket, and portfwd_worker()
closed its own copy of the same descriptor again at teardown. That was
unreachable while the library never emitted the action, which is why the
report against it was set aside; it is reachable now.
- record the cleanup in the forwarding state and skip the second close
- clear the shared descriptor when the exit path is the one that closes
it: the loop can leave with the channel still open, and freeing the
session then runs the handler on a descriptor already closed
- reset the record when a fresh forward's socket is adopted, or one left
by an earlier refused open skips closing a live socket at exit
- drop the handler comment saying the action is never emitted
WOLFSSH_FWD_LOCAL_CLEANUP now runs, and it runs from DoChannelClose()
ahead of the WS_CHANNEL_CLOSED the worker sees. The handler has already
closed the socket and moved the state on by then, so the recovery branch
no longer matched and left ssh_worker() holding a closed descriptor.
- guard the handler's close: the open can fail after the setup, with
nothing yet connected
- gate the handler on the channel id the library passes in the port
parameter. A channel can outlive its turn in the single forwarding
slot, and a cleanup arriving after the next forward has moved in
would close that one's live socket
- have the recovery branch clear its stale copy of the descriptor when
the handler got there first, and still do the whole teardown for a
locally opened forward, which draws no callback
- resolve the closed channel with wolfSSH_GetLastRxId(). wolfSSH_worker()
names the channel only for the data and EOF statuses, so the recovery
branch was comparing against a stale zero and ran only for a forward
that happened to be channel 0
- clear the pending direct connect as well: it is only cleared on
success, so a refused target left it set and the worker connected
again with the host name the handler had just freed
WOLFSSH_FWD_LOCAL_CLEANUP is part of the public WS_FwdCbAction contract
and the library never sent it, so an application's handler never ran and
every peer-opened forward leaked what its setup callback allocated.
ChannelDelete() now sends it, so a peer close, an open refused after the
setup ran, wolfSSH_ChannelFree(), and freeing the session all report it.
- record the setup in a new fwdSetupTxd bit on WOLFSSH_CHANNEL: a
locally opened forward gets no LOCAL_SETUP, so the channel type alone
cannot say whether the application holds anything
- clear the bit when the cleanup goes out, so a channel reports it once
- pass the channel's id in the port parameter, the way
WOLFSSH_FWD_CHANNEL_ID does, so an application with two forwards can
tell which one ended
- TestDirectTcpipFwdCbRejectsChannelId now counts three callback calls
scripts/fwd.test sends eight short lines, so nothing in the suite drives
a forwarding channel past its first window, and a forward that stalled
once the window needed crediting would go unnoticed.
- push a payload several windows long through a local direct-tcpip
forward and compare the bytes that arrive
- end a second transfer one window plus a short tail in, where the tail
is what portfwd still holds at end-of-input, and repeat it since the
window credit beating that tail is a race
- give the listening nc its stdin from a fifo a sleep holds open:
reading end-of-input makes nc close the connection, which truncates
the transfer and looks exactly like a stall
- bail out early once the byte count stops moving, so a real stall
reports in seconds
- dump the logs on failure, check the listening nc came up, and take
ports clear of the ones fwd.test.expect hardcodes, so a squatted or
shared port is not reported as a stall
A zero read on the local socket left the loop at once, and anything
read but not yet accepted by wolfSSH_ChannelSend() went with it. With
the peer's window full that tail is up to a buffer's worth, so a
transfer that ends while the window is being credited comes out short.
- stop polling the socket on end-of-input and keep looping until the
buffer is empty
- leave anyway once the channel is gone, so a forward whose open failed
cannot hold the loop on a buffer nothing can take
wolfSSH_shutdown() flushes whatever a short send left in the output
buffer, not just a queued disconnect. A rejected auth's
USERAUTH_FAILURE has no channel, and DoChannelClose() retires the
channel as soon as the close is bundled, so neither had anything
left to carry the retry.
- The gate still refuses a flush once the peer has disconnected,
unless our own disconnect is the thing queued.
- A flush that finishes on a live session clears the WS_WANT_WRITE
the short send latched, as the disconnected path already did.
- ssh.h documents the widened flush and the WS_WANT_WRITE a short
one leaves wolfSSH_shutdown() returning.
- Tests cover the rejected auth with no channel and the close whose
channel DoChannelClose() already retired.
- A flush that short-sends on a live channel leaves the teardown
queued behind it. The retry adds no second EOF or close, and skips
the close wait while its own flush is still short.
- A teardown send that drained the leftovers settles the flush; one
that failed outranks it, since a reset leaves the buffer intact.
Only the shell hook had coverage, so nothing held DoChannelRequest() to
handing the command and session type to the exec and subsystem callbacks
or to answering with what they return.
- assert each callback sees the session type and the command string the
request carried, and the ctx set on the session
- assert an accepting callback draws CHANNEL_SUCCESS and a rejecting one
CHANNEL_FAILURE, whether it rejects with a WS_ error or a bare nonzero
wolfSSH_CTX_SetChannelCloseCb() had no caller in tests/, examples/ or
apps/, so nothing held DoChannelClose() to running the hook before it
retires the channel.
- assert the callback runs with the closing channel's id and the ctx
set on the session
- assert the channel is still on the list inside the callback and gone
by the time the caller is told
- a rejecting callback changes nothing: the return is discarded and the
close completes
The confirmation and failure hooks reach an application only through
DoChannelOpenConf() and DoChannelOpenFail(), and nothing in tests/ or
apps/ registered either, so both arms shipped unexercised.
- assert the confirm callback runs with the peer's channel id, window
and packet size already recorded
- assert the failure callback runs while the channel is still findable,
before DoChannelOpenFail() removes it
- count each hook separately, so a test can tell which one ran
- a rejecting confirm hook fails the receive and leaves the open
unfinished; a rejecting failure hook fails it and leaves the channel
on the list
- seed the unconfirmed channel through ChannelNew() and ChannelAppend(),
the state an outstanding open leaves behind
When a test is configured out, its entry function compiles down to
"return 77", the automake skip code, and the main() that forwards to it
inlines to the same two instructions. Apple's ld folds the two identical
bodies together and then writes LC_MAIN entryoff 0, so the binary starts
executing at the Mach-O header and dies with SIGILL instead of skipping.
tests/kex.test, tests/api.test and tests/auth.test all hit this under
--enable-all CPPFLAGS=-DWOLFSSH_TEST_BLOCK, and kex.test hits it again
under --disable-server.
Probe for -Wl,-no_deduplicate and add it to AM_LDFLAGS when the linker
takes it. GNU ld rejects the flag, so the check leaves Linux alone.
Making the skipped body differ does not help: anything added to the entry
function inlines into main() and the two fold again.
sshd_sftp_idle_cpu_test.sh measures the connection process it forked, so
it takes the wolfsshd present after the connection and not before. The
old symmetric difference offered a pid that left during the window just
as readily, and the smallest one wins, so an earlier test's departing
child was measured through a /proc entry that no longer existed.
- compare the pid sets one way, and poll for the fork rather than
sampling a fixed five seconds in
- let the handshake and SFTP setup finish before the baseline, so their
ticks land outside the measurement rather than inside it
- print both pid sets when no child is found, since the failure says
nothing about which pids were considered
RFC 4254 6.1 has a session open travelling client-to-server, so
DoChannelOpen refuses one on a client endpoint in the type switch,
ahead of ChannelNew and any channelOpenCb. OpenSSH and Dropbear
refuse it outright too, with no application opt-in.
- Answer OPEN_ADMINISTRATIVELY_PROHIBITED, as the forwarded-tcpip
direction gate below it does.
- Widen the client harness guard in regress.c so it builds without
WOLFSSH_FWD, and hoist AcceptChannelOpenCb out of the forwarding
block.
- Cover the refusal, and the gate outranking an accepting
channelOpenCb.
Issue: F-8836
TestClientOnlyKexMsgsBlocked now asserts that 31 and 33, the ids a
client does receive, stay allowed where the handshake expects them, so
widening the role check into a 30-34 range fails the suite. The
IsMessageAllowed() comment records the receive-only policy and the
per-KEX-method id namespace.
- assert id 33 is allowed once expectMsgId is MSGID_KEXDH_GEX_REPLY
- assert expectMsgId starts at MSGID_NONE, so the role check is what
rejects the blocked ids
- recheck all three blocked ids during a rekey on an established session
wolfSSH_CTX_SetSshProtoIdStr() now rejects a string that is not
CRLF-terminated, exceeds 255 bytes counting the terminator, or
carries a CR or LF in the body. DoKexInit() subtracts the two
terminator bytes from the length when hashing it, so an
unterminated string underflowed the hash length.
Issue: F-10571
Gates ML-DSA composites behind WOLFSSH_NO_MLDSA_COMPOSITES.
Deduplicates key handling and uses heap allocation for
composite buffers when compiling for small stacks.
FwdRemoteSettle() folds a port-0 forward the peer bound onto a
registration already standing at that port. A request still in its
send window resolved its forward before the send, so it names the
survivor from here on, the same as the queued replies do.
- Add FwdPendingRebind() and call it ahead of the unlink, so a cancel
whose send pumped in the answer commits naming a forward rather
than nothing.
- Regression test drives the port-0 answer in from the cancel's send
callback.
FwdPendingCommit() looks for a registration of the bind its entry names
before linking it. An answer pumped in from the send can settle a
port-pending forward onto that port, and the fold in FwdRemoteSettle()
runs before the committing entry joins the list.
- replies queued against the folded entry move to the one that stands
at the bind
- test drives that answer from the IO send callback; the bind takes two
registrations without the fold, and one cancel leaves one matching
A request looked its registration up again at commit, after the send had
run the application's send and highwater callbacks. A callback that
reenters the library sends behind the request that ran it, so the lookup
found what the callback did rather than what the request asked for: a
cancel from a first setup's send found nothing to take, and that setup's
commit then registered the forward the peer had just been told to drop.
- Requests in flight hang off ssh->fwdPendingHead for the length of
their send, so a reentrant request resolves to the forward the request
it interrupted is registering, not to nothing.
- FwdRemotePrepare() settles what the request names and holds it on the
pending; FwdPendingCommit() uses that instead of a fresh lookup, which
also drops the dedupe branch the double lookup needed.
- FwdRemoteUnlink() voids the pending pointers along with the queued
slots, so freeing a forward mid-send leaves no commit naming it, and
FwdPendingDiscard() goes through it rather than freeing raw.
- FwdRemoteMatch() reads the pending list under the rules the scan over
registered forwards uses: a setup mid-send is on the wire and can feed
channels; a cancel behind it or a refusal on its slot stops matching.
- Drop pend->bindAddr and pend->bindPort, which nothing reads now.
- Tests drive a cancel, a setup, an inbound forwarded-tcpip open and a
mid-send REQUEST_FAILURE from the IO send callback, the window the
highwater tests no longer reach.
Issue: ZD-22195
The match only ran once wolfSSH_FwdRemoteSetup() had registered
something, so a client that never called it had every forwarded-tcpip
open go unchecked -- the case RFC 4254 7.2 is clearest about, since a
session that asked for no forward has nothing an open could answer for.
- Refuse the open whenever it names no registration, empty list
included. wolfSSH_SetFwdRemoteMatch(WOLFSSH_FWD_MATCH_OFF) is the
opt-out for an application that keeps its own bind list.
- Drop fwdRemoteTracked, which nothing reads now.
- wolfSSH_global_request() cannot carry the bind address and port RFC
4254 7.1 puts after the want-reply boolean, so no request that
registers a forward can be framed outside wolfSSH_FwdRemoteSetup().
Issue: ZD-22195
Aidan Keefe
Yosuke Shimizu
John Safranek
JacobBarthelmeh
Kareem
Emma Stensland
Reda Chouk
Hideki Miyazaki