* Add a new command line arg to enforce tls1.2
* Add better explanation of FreeRDP_EnforceTLSv1_2
(cherry picked from commit ce2e3ab0c7)
* Regenerated settings helpers
* backport prev cherry-pick
* Cleanup tls_prepare
* TLS version control
* added settings for minimal and maximal TLS versions supported
* refactorisation of the force TLSv1.2 setting
* cleanup from prev cherry-pick
* updated change log
Co-authored-by: akallabeth <akallabeth@posteo.net>
Co-authored-by: David Véron <david.veron@rubycat.eu>
* Moved clipboard utils to core library, fixes#6760
(cherry picked from commit 4fb686d40f)
* Fixed compilation warnings in cliprdr_utils
(cherry picked from commit 8b7a086411)
* Fixed backport API mismatch
* Added C++ guards to header
(cherry picked from commit 7626a2ce6a)
* codec/progressive: Fix wrong usage of subband diffing flag (#8076)
Currently, all Calista Progressive encoded streams contain tile
artifacts, when the RFX_SUBBAND_DIFFING is used, but not the
RFX_DWT_REDUCE_EXTRAPOLATE flag.
The reason is the wrong usage of the context and tile flags.
The RFX_SUBBAND_DIFFING flag should have no actual impact on the
decoder itself.
Especially, it does not affect the band sizes within a 64x64 tile.
The RFX_DWT_REDUCE_EXTRAPOLATE flag, on the other hand, MUST have an
effect on the band sizes.
However, FreeRDP currently uses the RFX_SUBBAND_DIFFING flag when
decoding a component to determine whether the Reduce-Extrapolate method
is used, resulting in tile artifacts, when that method was actually not
used.
The current behaviour did not result in tile artifacts with the MS
Windows RDS, as that server always sets both flags.
So, fix this issue by using the correct flag, when decoding a tile.
* Update changelog
Microsoft Windows imposes strict filename restrictions on its platform.
As RDP is developed by Microsoft and the RDS in MS Windows is typically
used as remote desktop server for the RDP protocol, these filename
restrictions are also enforced in WinPR, when copy-pasting files over
the clipboard.
However, in some connections no peer on MS Windows is involved and in
these situations, these filename restrictions are just an annoyance.
With a recent API addition in WinPR, it is now possible to override the
callback, where the filename is checked, whether it is valid.
So, use this new API to relieve the filename restriction, when the
connected remote desktop server is not on MS Windows.
With LibreSSL 2.7.0 (or newer versions) some more structs have made
opaque, which requires a few changes:
- BIO_meth_new() and related functions are now defined by LibreSSL, the
versions from opensslcompat.{h,c} does not need to be used anymore.
- HMAC_CTX is now opaque, HMAC_CTX_new(), EVP_MD_CTX_new, and related
functions should be used instead in winpr's hash.c.
This allows server implementations to add handling for situations,
where the client side does not support them.
Particularly useful for the audio output channels (static channel as
fallback, when dynamic channel is not supported).
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)
