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.
This reverts commit 402801e0a6.
We should use UTF8 throughout the application and convert to platform
encodings only at the edge. Otherwise it's not clear which data uses
which encoding and we result in extremele brittle system.
We have a check for windows here anyway, let's move the defines here and we
can drop it in the common header file. And since on Unix HAVE_CONFIG_H is
always defined, we can drop the else condition too.
The following logs are extracted from pasting texts to Firefox's address
bar and a Google Doc page in Firefox, respectively.
[2021-05-16T00:03:14] DEBUG1: request for clipboard 342, target text/plain;charset=utf-8 (600) by 0x03000044 (property=GDK_SELECTION (511))
[2021-05-16T00:03:22] DEBUG1: request for clipboard 342, target application/x-moz-nativehtml (603) by 0x03000044 (property=GDK_SELECTION (511))
Inspired by https://github.com/debauchee/barrier/pull/461. Should fix
pasting unicode on X11 https://github.com/debauchee/barrier/issues/344.
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.
The non-ASCII symbols missing in CP_THREAD_ACP but present in current KB
layout were processed incorrectly. Do not rely on ANSI => UTF16
conversion, obtain UTF16 directly from KB layout driver. BTW, ToAscii is
implemented via ToUnicode + RtlUnicodeToMultiByteN, so this is really
optimization.
cmake sets HAVE_DPMS_PROTOTYPES unconditionally to 1 if we have the dpms
headers. So code inside HAVE_X11_EXTENSIONS_DPMS_H never needs to check for
it.
And since there's only one place that cared for this, we can remove the define
in cmake as well.
