mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-11 16:18:06 -05:00
9e09915157
ssh2_scan_kexinits must check to see whether it's behaving as an SSH client or server, in order to decide whether to look for "ext-info-s" in the server's KEXINIT or "ext-info-c" in the client's, respectively. This check was done by testing the pointer 'server_hostkeys' to see if it was non-NULL. I think I must have imagined that a variable of that name meant "the host keys we have available to offer the client, if we are the server", as the similarly named parameter 'our_hostkeys' in write_kexinit_lists in fact does mean. So I expected it to be non-NULL for the server and NULL for the client, and coded accordingly. But in fact it's used by the client: it collects host key types the client has _seen_ from the server, in order to offer them as cross- certification actions in the specials menu. Moreover, it's _always_ non-NULL, because in the server, it's easier to leave it present but empty than to get rid of it. So this code was always behaving as if it was the server, i.e. it was looking for "ext-info-c" in the client KEXINIT. When it was in fact the client, that test would always succeed, because we _sent_ that KEXINIT ourselves! But nobody ever noticed, because when we're the client, it doesn't matter whether we saw "ext-info-c", because we don't have any reason to send EXT_INFO from client to server. We're only concerned with server-to-client EXT_INFO. So this embarrassing bug had no actual effect.