- endgame story makes both mechanisms real: consumer binds the produced
SOCKS5 resource locally (optional front door, ssh -D shape without
the forced bind) and points tun2proxy at it
- producer side: identity seam only (CF-005/CF-006); a password there
is moot against the ACL system — in-band conversation runs NoAuth
- consumer front door: owns RFC 1929 where vanilla clients need it
(tun2proxy/curl user:pass), maps accepted credentials to the channel
identity it opens the producer with; the SOCKS password never crosses
the channel as a SOCKS password
- replace-or-second-gate sub-question dissolves: the mechanisms occupy
different planes (door-local creds vs channel-level identity)
- remaining for Phase 1: credential->identity mapping shape; producer-
side local backend door surface; AuthMethod trait vs door-owned check
glm-5.3-flash
4730672f10