* Fixed typo in changelog
* Fix FIPS mode support and build with OpenSSL 3.0
FreeRDP fails to build with OpenSSL 3.0 because of usage of the `FIPS_mode`
and `FIPS_mode_set` functions, which were removed there. Just a note that
the FIPS mode is not supported by OpenSSL 1.1.* although the mentioned
functions are still there (see https://wiki.openssl.org/index.php/FIPS_modules).
Let's make FreeRDP build with OpenSSL 3.0 and fix the FIPS mode support.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1952937
(cherry picked from commit 26bf2816c3)
* winpr: avoid calling FIPS_mode() with OpenSSL 3.0
Fixes: 26bf2816c3
(cherry picked from commit 0c81c73c8d)
* winpr/crypto: Load legacy provider to fix rc4 with OpenSSL 3.0 (#7210)
* winpr/crypto: Exit cleanly when EVP_EncryptInit_ex fails
The `EVP_EncryptInit_ex` function may fail in certain configurations.
Consequently, FreeRDP segfaults in `EVP_CIPHER_CTX_set_key_length`.
Let's handle the `EVP_EncryptInit_ex` failures and exit cleanly in
such case.
* winpr/crypto: Load legacy provider to fix rc4 with OpenSSL 3.0
Currently, the `EVP_EncryptInit_ex` function fails for rc4 with OpenSSL 3.0.
This is becuase rc4 is provided by the legacy provider which is not loaded
by default. Let's explicitly load the legacy provider to make FreeRDP work
with OpenSSL 3.0.
Relates: https://github.com/openssl/openssl/issues/14392
Fixes: https://github.com/FreeRDP/FreeRDP/issues/6604
(cherry picked from commit 67f3fff2c8)
Conflicts:
winpr/libwinpr/crypto/cipher.c
* Fix TestUnicodeConversion on big endian machines (#7219)
Wide character literals are stored in native byte order.
Use an array of bytes as a reference instead.
Fixes: https://github.com/FreeRDP/FreeRDP/issues/6968
(cherry picked from commit 5208a67ea7)
* Fixed async-input quit
* Fix data write on usb channel
* Bitmap update fix (#7349)
* Added checks for bitmap width and heigth values
Data received from the server might have invalid values for bitmap
with or height. Abort parsing if such a value is found.
Reported by Sunglin from the Knownsec 404 team & 0103 sec team
* Added checks for glyph width & height
* Fixed#7363: Length checks in ConvertUTF8toUTF16
(cherry picked from commit 623a77258a)
* Implemented missing TSG debug functions
(cherry picked from commit c06c463806)
* Refactored RPC gateway parser
Utilize wStream instead of custom binary parsing code, add proper
input validation.
Reported by Sunglin from the Knownsec 404 team & 0103 sec team
(cherry picked from commit f0b44da67c)
* Replaced chmod with safer fchmod
* Use fchmod so the file may not change underneath
* Add unit tests for SetFileAttributesA
* Add warning logs for unsupported flags
(cherry picked from commit c8571dd5fd)
* Updated changelog and version
* Added more explicit warning for deprecated command line
* Add exit codes for more errors
(cherry picked from commit aa4c3dfb8a)
* Updated changelog.
Co-authored-by: Ondrej Holy <oholy@redhat.com>
Co-authored-by: Mike Gilbert <floppym@gentoo.org>
Co-authored-by: Ondrej Holy <ondrejholy@users.noreply.github.com>
Co-authored-by: Ian Weir <mr.weir@me.com>
Functions like fopen, PathFileExists, PathMakePath need to call
the wide character versions on windows for utf-8 support.
(cherry picked from commit 6b36c6d417)
For the negative scrolling direction, RDP uses the two's complement,
instead of the positive wheel value with the negative flag.
xfreerdp currently uses the positive wheel value in addition to the
negative flag, which results in a wrong wheel value on the server side
(136 instead of 120).
Fix this, by using the correct wheel rotation value, which is in the
two's complement.
(cherry picked from commit 1087a5e1a6)
Changed the logic of the disp channel to wait for 800ms after a
ConfigureNotify before sending the new resolution.
The problem fixed with this patch is the following:
1. Resize the window with the mouse
2. ConfigureNotify triggers a resize notification
3. The server resizes to the desired resolution
3a. More ConfigureNotify events are generated
4. The local window resize to the new resolution triggers another
ConfigureNotify
a. Depending on the timing (sending is already rate limited) the
events from 3a and 4 will make the size of the window jump
b. Very fast resizing will pick a random resolution from the
sequence of ConfigureNotify events as the final resolution
(cherry picked from commit d3ed42a799)
I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
(cherry picked from commit 64948b96c4)
Now you can give an option the combination of flags
COMMAND_LINE_VALUE_OPTIONAL and COMMAND_LINE_VALUE_BOOL. If you do,
then all three of the syntaxes +foo, -foo and /foo:value are allowed
at once, and the receiving code can tell the difference because the
Value field is set to BoolValueTrue, BoolValueFalse or a valid char
pointer.
(cherry picked from commit 22c6b375d4)
A selection owner is supposed to respond to a request for the
selection target TIMESTAMP by providing the X server time at which the
selection was written. There was a /* TODO */ comment in xf_cliprdr
where the code to do that should have been.
The absence of this can cause a problem when pasting into some X
clients. xtightvncviewer, in particular, will give up the attempt to
read from the clipboard at all if it doesn't get a satisfactory
response to the initial TIMESTAMP request - and the non-answer zero
value "CurrentTime" counts as unsatisfactory. It won't be happy with
anything short of a real X server time value.
(Checking the VNC source code, that's because it reads both PRIMARY
and CLIPBOARD and picks the one with the later timestamp. So it does
depend on the timestamps existing.)
When you're writing to the selection in response to a normal X event
like a mouse click or keyboard action, you get the selection timestamp
by copying the time field out of that X event. Here, we're doing it on
our own initiative, so we have to _request_ the X server time. There
isn't a GetServerTime request in the X protocol, so I work around it
by setting a property on our own window, and waiting for a
PropertyNotify event to come back telling me it's been done - which
will have a timestamp we can use.
(cherry picked from commit fcabbc9707)
* The display resolution change message was prone to a race condition
* Check for actual fullscreen state instead of settings
* Assume 75dpi for display resolution to mm conversion
(cherry picked from commit 13c8a60b70)
If a request was pending and new formats were announced the response
to a ServerFormatDataRequest was never sent.
(cherry picked from commit 2efb7d9274)
Currently, non-zero exit code is returned for /version, /buildconfig, /help,
/monitor-list, /kbd-list and /kbd-lang-list command-line options for several
clients. This is against conventions because 0 is usually returned in
such cases. Also, there is potentially another problem that the returned
codes overflow on UNIX systems (where the exit code is a number between 0
and 255). Let's fix the clients to return 0 in the mentioned cases to honor
conventions and 1 for the command-line parsing errors (or -1 for clients
who already use that value).
Fixes: https://github.com/FreeRDP/FreeRDP/issues/6686
(cherry picked from commit 3ee4cabcfa)
