For the time being both SHA1 and SHA256 fingerprints will be shown in
the UI. This allows users to verify new connections between old and new
versions of Barrier. After the initial verification we use SHA256
fingerprints.
The issue has been reported by Matthias Gerstner <mgerstner@suse.de>.
This fixes#976, fixes#974, fixes#444.
On Windows the standard stream open() functions expect bytes encoded in
current system encoding, not UTF8. Since we're dealing with UTF8
throughout the application this results in wrong paths being passed and
failure to open files. As a solution, we convert the paths to UTF16 via
the WCHAR character type and use the special Windows-specific overloads
of open() functions.
The SSL_get_client_ciphers API has been available since LibreSSL 2.9.1
and is thus present in all supported versions (3.2.x and 3.3.x). In
the upcoming LibreSSL 3.4.x release the SSL_CIPHER struct will become
opaque hence the build will break.
Many tools strip trailing whitespaces by default, so after editing a file with
whitespace errors we end up with a bunch of unrelated hunks that need to be
reverted locally.
This could be fixed by configuring each tool to not do this (at least for the
barrier repo), or, simpler, we just sed the problem away and make barrier
whitespace-compliant.
sed commands run:
sed -i 's/[ \t]\+$//' **/*.(cpp|h) **/*CMakeLists.txt
Verified with git diff --ignore-space-change, this shows the empty diff.
The commit a841b28 changed the condition for removing job from processing.
New flag MultiplexerJobStatus::continue_servicing become used
instead of checking pointer for NULL.
However for cases when TCPSocket::newJob() returns nullptr
the behaviour changed: earlier the job was removed, but after change
it is called again, since MultiplexerJobStatus equal to {true, nullptr}
means "run this job again".
This leads to problem with eating CPU and RAM on linux
https://github.com/debauchee/barrier/issues/470
There is similar windows problem, but not sure it is related.
https://github.com/debauchee/barrier/issues/552
Since it looks that the goal of a841b28 was only clarifying
object ownership and not changing job deletion behaviour,
this commit tries to get original behaviour and fix the bugs above
by returning {false, nullptr} instead of {true, nullptr}
when TCPSocket::newJob() returns nullptr.
