The sesman tools have some private functions to make syncronous calls
to sesman over SCP. This commit moves these calls to a new module
scp_sync in libipm so that they can be utilised by other parts of
xrdp (i.e. chansrv)
THe function xrdp_sec_in_mcs_data() parses data within the
TS_UD_CS_CORE struct which could just as easily be parsed
when xrdp_sec_process_mcs_data_CS_CORE() is called.
Currently the contents of the MSC Connect Initial PDU are stored within
the client_mcs_data member of the xrdp_sec struct. This stream is parsed
once by xrdp_sec_process_mcs_data() and then separately by
xrdp_sec_in_mcs_data(). There is no reason not to perform the parse in
a single pass through the stream.
This commit folds the functionality in xrdp_sec_in_mcs_data() into
xrdp_sec_process_mcs_data_CS_CORE() and removes xrdp_sec_in_mcs_data()
We always now indicate we support skipping channel joins. If the client
indicates this too, expect no channel join requests from the client.
If we do get some, process them anyway.
The existing code contains separate TLS and non-TLS code paths for
hadling channel join PDUs. This was introduced in
8fdc1ba216 and was based on a
misunderstanding of where in the connection sequence the TLS client hello
is processed (if a TLS connection is negotiated). The assumption was
the TLS client hello is received after the channel join PDUs. However,
it is actually received immediately after the X.224 Connection Confirm
PDU some time before channel join requests are processed.
Consequently, there is no reason not to adopt a single code path for
handling channel joins.
This is a regression introduced in v0.10.x
This version introduced a state machine to handle resizes requested
by the client and the server. Most configurations support resizeable
sessions, but one that doesn't is xrdp connecting to x11vnc on (e.g.) a
Raspberry PI.
If the session size requested by a client is differnt from the x11vnc
size, an error is logged and the state machine fails to complete,
resulting in a black screen.
This PR handles the problem by queueing a resize to the supported
server size and then continuing with the state machine. It's not an
optimal solution, but involves the least change to v0.10.x code.
Version 2.14.0 of cppcheck generates errors relating to the
check level (e.g.):-
common/base64.c:0:0: information: Limiting analysis of branches. Use --check-level=exhaustive to analyze all branches. [normalCheckLevelMaxBranches]
This does not happen with the same sources (commit
f781962a55) under 2.13.0.
This PR disables the warnings above for 2.14.0, but also allows a '-f'
argument to be passed in to request an exhaustive test. This could be used
(for example) before a major release. An exhaustive test takes a *lot*
longer. The first run with a git runner was around an hour.
The --check-level=flag was only added for 2.11.0, and so this now needs
a version check.
- Fix CI errors
- tconfig_load_gfx() removes H.264 from the supported codec list
if significant errors are found loading the H.264 configuration
- tconfig_load_gfx() always produces a usable config, even if the
specified file can't be loaded
