Since Windows doesn't use id-pkinit-san in its certificates, it is
necessary to manually configure which hosts are valid KDCs. In the case
where a kdcUrl (or hostname) is provided to us, we can do that
configuration ourselves.
Server side we often see "FreeRDP_ChannelDefArray::len expected to be >= 31,
but have XXX", where XXX is lower than 31.
This patche fixes that, the old code was setting the size of ChannelDefArray to the
number of ChannelCount, which is usually not what we want. We want to keep it to 31
and have ChannelCount indicate how many of these channels are used.
To simplify building external channels and other plugins related
paths are now exported in the pkg-config file and the cmake package.
The paths can be used to install channels/plugins/extensions in
the configured search paths.
For pkg-config the following variables are now available:
* datadir
* plugindir
* proxy_plugindir
* extensiondir
They can be queried like: `pkg-config freerdp3 --variable plugindir`
The cmake package has three new variables that can be used:
* FreeRDP_PLUGIN_DIR
* FreeRDP_PROXY_PLUGIN_DIR
* FreeRDP_EXTENSION_DIR
Note: Depending on the build the directories are not necessarily created.
* unify reading of domain and username strings with all the checks
* add handling of (undocumented) padding in [MS-RDPBCGR]
2.2.10.1.1.2 Logon Info Version 2 (TS_LOGON_INFO_VERSION_2)
occurring with windows 11
CertificateContent and PrivateKeyContent now have two valid formats:
It can be in format PEM (multiple lines) or a single line base64 encoded
PEM.
The first format is preferrable in case the pf_config* API is used to
set the certificate/key, the latter in case an actual config file is in
use where multiline configuration data can not be directly entered.
* move type definition to WinPR as used there too.
* supported keyboard types are defined in
[MS-RDPBCGR] 2.2.1.3.2 Client Core Data (TS_UD_CS_CORE)]
use a enum instead of magic numbers to make code more readable.
WinPR provides APIs to convert between keycodes between virtual
keycodes.
These keycodes can currently be evdev keycodes or Apple keycodes.
The evdev handling, however, handles XKB keycodes and not evdev ones.
The main difference between these is that XKB keycodes are shifted by
the value 8, compared to evdev keycodes.
In order to fix this situation, rename the evdev keycodes to XKB ones,
and introduce additionally a new keycode evdev, including its handling
for this keycode type.
Commit 2de7a4c249 introduced major changes
in the gateway authentication code. One of these changes was to decouple
NTLM specific authentication from the gateway code.
However with these changes, gateway authenciation with the old RPC code
stopped working and returned an authentication error. The problem is
that currently `credssp_auth_encrypt` encrypts the given message along
creating a signature.
The old code prevented encryption of the message by specifying
`SECBUFFER_READONLY` on the message buffer. The native Windows SSPI then
leaves this buffer as-is and gateway authentication works again.
This fix only applies to Windows platforms using the native SSPI API.
Interestingly this works on other platforms using the WinPR SSPI so
there seems to be a difference between the implementations (but that's a
topic for another PR).
Some PDUs, like the Activate Device Request only contain the header.
As a result, the size of the rest of the PDU is 0.
The assertion for the PDU size in device_server_packet_new only
considers the size of the body of the PDU.
When that value is 0, the assertion is hit and the server implementation
crashes.
To fix this issue, simply remove this assertion. Since the allocation
size is always at least the header size, there won't ever be an attempt
to create a stream with a size of 0.
The decoded base64 data might contain PEM with/without/with multiple
'\0' at the end of the string. We do not want to drag this through our
code so ensure the length matches the string length including '\0'
When receiving a file list, xfreerdp3 rebuilds the content of the FUSE
filesystem.
Since fetching uri-lists can happen during a paste action too, xfreerdp3
caches the content of the last fetched mime type.
However, uri-lists exists in different variations, e.g. nautilus uses a
different mime type, than gnome-terminal does.
Furthermore, FormatLists can also contain other formats in addition to
file lists.
Fetching those contents during a paste operation leads to IO errors in
the paste operation.
In order to fix those errors, cache every mimetype in two hash tables:
One for the raw (unconverted) data, and one for the converted data.
When a content request is received, xfreerdp3 can with the already
cached converted data, directly serve the data.
If the content is not available as cached data, but its source data was
already fetched, use that source data to create the converted data.
Then serve the converted data.
Only if no cached converted data or cached raw data is available, issue
a new FormatDataRequest.
The attributes xPos and yPos for a Color Pointer Update are confusing,
as they may be confused with the xPos and yPos of the pointer bitmap on
the actual screen.
Rename these attributes to what they actually represent, and that is the
hotspot position.
xPos and yPos are still members of the hotspot. However, hotSpotX and
hotSpotY are much more clearer.
In addition to that, the Large Pointer Update uses the same names for
the hotspot coordinates.
