1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 01:48:00 +00:00
putty-source/utils/CMakeLists.txt

63 lines
1.0 KiB
CMake
Raw Normal View History

add_sources_from_current_dir(utils
antispoof.c
backend_socket_log.c
base64_decode_atom.c
base64_encode_atom.c
bufchain.c
buildinfo.c
burnstr.c
chomp.c
conf.c
conf_dest.c
conf_launchable.c
ctrlparse.c
debug.c
Add 'description' methods for Backend and Plug. These will typically be implemented by objects that are both a Backend *and* a Plug, and the two methods will deliver the same results to any caller, regardless of which facet of the object is known to that caller. Their purpose is to deliver a user-oriented natural-language description of what network connection the object is handling, so that it can appear in diagnostic messages. The messages I specifically have in mind are going to appear in cases where proxies require interactive authentication: when PuTTY prompts interactively for a password, it will need to explain which *thing* it's asking for the password for, and these descriptions are what it will use to describe the thing in question. Each backend is allowed to compose these messages however it thinks best. In all cases at present, the description string is constructed by the new centralised default_description() function, which takes a host name and port number and combines them with the backend's display name. But the SSH backend does things a bit differently, because it uses the _logical_ host name (the one that goes with the SSH host key) rather than the physical destination of the network connection. That seems more appropriate when the question it's really helping the user to answer is "What host am I supposed to be entering the password for?" In this commit, no clients of the new methods are introduced. I have a draft implementation of actually using it for the purpose I describe above, but it needs polishing.
2021-10-24 08:18:12 +00:00
default_description.c
dupcat.c
dupprintf.c
dupstr.c
encode_utf8.c
encode_wide_string_as_utf8.c
fgetline.c
host_strchr.c
host_strchr_internal.c
host_strcspn.c
host_strduptrim.c
host_strrchr.c
log_proxy_stderr.c
marshal.c
memory.c
memxor.c
miscucs.c
null_lp.c
nullseat.c
nullstrcmp.c
out_of_memory.c
parse_blocksize.c
prompts.c
ptrlen.c
read_file_into.c
seat_connection_fatal.c
sessprep.c
sk_free_peer_info.c
smemclr.c
smemeq.c
ssh2_pick_fingerprint.c
sshutils.c
strbuf.c
string_length_for_printf.c
stripctrl.c
Allow new_connection to take an optional Seat. (NFC) This is working towards allowing the subsidiary SSH connection in an SshProxy to share the main user-facing Seat, so as to be able to pass through interactive prompts. This is more difficult than the similar change with LogPolicy, because Seats are stateful. In particular, the trust-sigil status will need to be controlled by the SshProxy until it's ready to pass over control to the main SSH (or whatever) connection. To make this work, I've introduced a thing called a TempSeat, which is (yet) another Seat implementation. When a backend hands its Seat to new_connection(), it does it in a way that allows new_connection() to borrow it completely, and replace it in the main backend structure with a TempSeat, which acts as a temporary placeholder. If the main backend tries to do things like changing trust status or sending output, the TempSeat will buffer them; later on, when the connection is established, TempSeat will replay the changes into the real Seat. So, in each backend, I've made the following changes: - pass &foo->seat to new_connection, which may overwrite it with a TempSeat. - if it has done so (which we can tell via the is_tempseat() query function), then we have to free the TempSeat and reinstate our main Seat. The signal that we can do so is the PLUGLOG_CONNECT_SUCCESS notification, which indicates that SshProxy has finished all its connection setup work. - we also have to remember to free the TempSeat if our backend is disposed of without that having happened (e.g. because the connection _doesn't_ succeed). - in backends which have no local auth phase to worry about, ensure we don't call seat_set_trust_status on the main Seat _before_ it gets potentially replaced with a TempSeat. Moved some calls of seat_set_trust_status to just after new_connection(), so that now the initial trust status setup will go into the TempSeat (if appropriate) and be buffered until that seat is relinquished. In all other uses of new_connection, where we don't have a Seat available at all, we just pass NULL. This is NFC, because neither new_connection() nor any of its delegates will _actually_ do this replacement yet. We're just setting up the framework to enable it to do so in the next commit.
2021-09-13 16:17:20 +00:00
tempseat.c
tree234.c
validate_manual_hostkey.c
version.c
wcwidth.c
wildcard.c
write_c_string_literal.c
x11authfile.c
x11authnames.c
x11_dehexify.c
x11_identify_auth_proto.c
x11_make_greeting.c
x11_parse_ip.c)