mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 08:02:24 +00:00
l0ng-ai
acd7d69815
Differential-tested the ssh_config parser against `ssh -G`: `Host=name`, keyword case, tabs, multiple patterns on a line, negation, first-value-wins across blocks, `%h`, quoted ProxyCommand, a `#` mid-value not being a comment, glob includes, the `Host *` fallback. All agreed. Host patterns are case-sensitive in OpenSSH and case-sensitive here, which also agreed. Forwards did not. OpenSSH takes a Unix socket on either end and a service name wherever a port goes — `ssh -G` accepts `LocalForward /tmp/my.sock localhost:80`, `LocalForward 8080 /tmp/remote.sock`, and resolves `localhost:http` to port 80. A `ForwardRule` is a host and a `u16`, so `parse_forward_rule` returns `None` for every one of them and the rule never reaches the profile. Not being able to hold those is a limitation and is now written down. What made it a bug is that the import report answered by keyword alone: `localforward` was on the supported list, so the report claimed a forward it had thrown away. Someone whose tunnel never came up had nothing to read — the report said it was there. The supported-list check now takes the value and, for the three forwarding keywords, asks whether the rule actually parses. It stays one list, so the resolver and the report cannot drift apart. `docs/remote/ssh.mdx` lists the omission beside `Match` and GSSAPI, and the guard reads that line as well as checking that the forwards which do fit still come across untouched — otherwise honesty could have been bought by reporting everything. Checked against an injected regression.