FTPD: relink against current libc370 (recovery-exit SDWACLUP hardening) — do not wait for a tag

[mgrossmann]

Summary

libc370 landed recovery-exit hardening this week. mvsMF and httpd were relinked
and deployed on 2026-07-26; ftpd was not. Decision recorded here: relink now,
do not wait for a tag. This issue tracks the action.

Why now

PR #65 (merged 2026-07-25, 7838a2b, closes #63) added ESTAE recovery around
per-command processing — ftpd_run_command() is driven through try() in
src/ftpd#ses.c. That try() path is exactly what the libc370 fix repairs:
the SDWACLUP guard had originally landed on an unreachable copy of the file, and
the reachable failed() in @@@try.c was left unguarded.

So ftpd's newest code is the code most exposed. Every command dispatched today
runs its recovery through the unfixed exit.

The MTT walk fix is not relevant to ftpd — confirmed by inspection, no
cmtt_get_array / MTT use anywhere in src/ or include/.

Why waiting for a tag buys nothing

libc370 is the cc370 sysroot (-lc), not a declared dependency. mbt.lock
pins only mvslovers/ufsd. There is no version pin for libc370 in this project's
build at all — a link picks up whatever archive is installed at
<prefix>/cc370/lib/libc.a, tagged or not.

Separately, the existing v1.0.0 tag on libc370 is 2a9f02d, which predates
both fixes:

72723da  2026-07-25 20:43  fix(recovery): honor SDWACLUP in reachable failed()  (#16)
2789f52  2026-07-25 20:43  fix(cmtt): validate whole MTT entry / mtentlen       (#14/#15)
b0744b0                    chore: bump to 1.0.1-dev
2a9f02d                    release: v1.0.0                          <-- tag v1.0.0

Pinning to v1.0.0 would therefore link less than current main. The hardening
is 1.0.1-dev content.

Sysroot state — already current for this fix

Verified rather than assumed. The installed archive
(<prefix>/cc370/lib/libc.a, 2026-07-25 20:47) was built from a tree at
libc370 a9e3442, and git diff a9e3442 origin/main -- '*try*' is empty — the
@@@try.c content is identical to 72723da on main. @@@try.o and @@abrpt.o
in the libc370 build tree carry the same 20:47 timestamp.

So no libc370 rebuild is required for ftpd. A relink alone picks the
hardening up.

One provenance caveat, not a blocker: that archive was built from a fix branch
rather than from main, so it does not carry 2789f52 (#14/#15). ftpd does not
consume cmtt_get_array, so this does not affect ftpd. A rebuild from current
main before the relink would make the deployed binary's provenance exactly
"libc370 main", which is tidier if anyone later has to reason about what shipped.

Action

make clean && make      # relink against the current sysroot
make deploy             # touches MVS

Optionally rebuild + install libc370 from current main first, for the
provenance reason above.

Verify after relink

• /S FTPD clean, /F FTPD,VERSION responds
• A session survives an induced command ABEND and the worker stays up
  (the FTPD: ESTAE-style recovery around per-command processing (try()/tryrc()) — an ABEND must not kill the worker #63 / Add ESTAE recovery around per-command processing (try()/tryrc()) #65 recovery path — that is the behaviour the fix protects)
• /P FTPD shuts down cleanly

References

• Add ESTAE recovery around per-command processing (try()/tryrc()) #65 / FTPD: ESTAE-style recovery around per-command processing (try()/tryrc()) — an ABEND must not kill the worker #63 — the try()/tryrc() recovery this fix protects
• src/ftpd#ses.c — ftpd_run_command(), try()-wrapped dispatch