Openssl 3.0 requires to respond to this controls. According to there
documentation it should not need them, but in practice openssl's own source
is full of places where negative return values are not checked.
(cherry picked from commit 9d7c20ce8f)
Connections with windows 2016 and 2019 sometimes receive short
frame marker. Ignore these to prevent disconnects
(cherry picked from commit 91ef44ed35)
If freerdp_abort_connect is called, set FREERDP_ERROR_CONNECT_CANCELLED
This way freerdp_reconnect can distinguish between network issues and
user interaction and abort a retry attempt.
(cherry picked from commit a6b42ff6c9)
{channels/tsmf/client/ffmpeg/tsmf,libfreerdp/codec/dsp}_ffmpeg.c:
Guard calls to `avcodec_register_all()` against use beyond
`AV_VERSION_INT(58, 10, 100)`, where upstream ffmpeg made it obsolete.
(cherry picked from commit 811d94c742)
When uploading large ICON (96x96), we end up growing the stream
mid-update. Stream_EnsureCapacity end up reallocating the stream
with a larger capacity to accomodate the large ICON size, but in
doing so, also updating the sealed length for the data currently in
the stream. This breaks the assumption between update_begin_paint
and update_end_paint where the sealed lenght is used to keep track
of the location where we need to update the orders counts after
we're done accumulating update. As a result of the growth and lost
of that location, the number of orders is written to the wrong
location and the resulting stream is invalid which result in a
protocol violation and a connection drop.
The current fix uses a new offsetOrder in the update object to
keep track of where update_end_paint needs to write the number
of orders contained. I think a better fix would be for
Stream_EnsureCapacity to preserve the sealead length of the
stream on growth, but this has a much more significant impact and
careful analysis needs to be done to ensure this doesn't violate
other assumption. Need to follow up with FreeRDP developer to get
their take on this one.
SSL will become opaque in LibreSSL 3.4.x, hence the code reaching inside
it will result in build breakage. This was done at the time for lack of
BIO_up_ref() support, which has been available since LibreSSL 2.7.0, so
adjust the relevant #ifdefs accordingly.
(cherry picked from commit ad0b6c377d)
* 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)
While decoding RemoteFX encoded frames is multithreaded, decoding
RemoteFX Progressive frames is not, although both codecs work
relatively similarly.
This is especially noticeable with frames, that have a resolution
larger than 1920x1080 pixels.
decompress_tile_first() and decompress_tile_upgrade() can both run in
different threads at the same time for different tiles without necessary
adjustments.
So, do exactly that using the ThreadPool that already exists in the
RFX_CONTEXT to decrease the decoding time and therefore increase the
performance.
On a 3K display (2880x1620 pixels) this makes out of a choppy
experience a fluid experience.
(cherry picked from commit e79fefe21c)
When checking whether tiles and updatedTileIndices are both non-NULL,
one of them might be NULL, while the other struct member might not
be NULL and progressive_surface_context_new() leaks then the non-NULL
struct member.
Fix this by freeing both struct members, when aborting in
progressive_surface_context_new().
free() will take no action on pointers that are NULL, so no additional
check is needed.
(cherry picked from commit 805dc60e14)
