[pull] main from TurboVNC:main #6
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1bc1b17 to
ab45e77
Compare
CMake 3.16 now includes an OBJC language, so we need to enable that language rather than fooling CMake into compiling the .m files by labeling them as C code.
(regression introduced by e402185) Setting a maximum version in cmake_minimum_required() effectively sets the behavior to NEW for all policies introduced in all CMake versions up to and including that maximum version. The NEW behavior for CMP0091, introduced in CMake 3.15, uses CMake variables to specify the MSVC runtime library against which to link, rather than placing the relevant flags in CMAKE_C_FLAGS*. Thus, replacing /MD with /MT in CMAKE_C_FLAGS* no longer has any effect when using CMake 3.15+.
... to silence deprecation warning regarding Node.js 12 and 16 actions.
bzip2, FreeType, and libfontenc are dependencies of XFont2, and the X server does not use them directly. Thus, they need not explicitly be included in the build when TVNC_SYSTEMLIBS and/or TVNC_SYSTEMX11 is set.
(macos-11 is deprecated, and Monterrey with Xcode 13.2.x matches our official macOS build configuration.)
This eliminates various build system hacks. Among the platforms that TurboVNC currently supports, only RHEL 7 doesn't have CMake 3.16+ yet, and RHEL 7 will be EOL before TurboVNC 3.2 is released. Also, it's easy enough to install a newer version of CMake into a non-system directory if the system-supplied version isn't new enough. (Our official Linux build image already does that.) This commit also modifies the Xvnc build system so that it uses imported targets for OpenGL and OpenSSL. We don't use imported targets for the various X11 libraries, because doing so would necessitate 8000 calling target_link_libraries() to specify every dependency (including indirect dependencies) between every Xvnc module and every X11 library. That would make the build system more complex and error-prone. Imported targets are really more suitable for single-scope dependencies. This commit also significantly streamlines the TurboVNC Viewer build, in exchange for requiring CMake 3.21+. (The need to include a resource, namely the timestamp file, with no file extension and located under the build directory, necessitates the RESOURCES option to add_jar(), which was introduced in CMake 3.21.)
TurboVNC 3.2 will no longer provide 32-bit Windows packages. Windows 10 no longer supports 32-bit-only x86 CPUs, and Windows 11 never did. Referring to https://turbovnc.org/Documentation/OSSupport, it is expected that the community will report any incompatibilities between TurboVNC and 32-bit-only operating systems, as well as assist in diagnosing and fixing such incompatibilities. In other words, TurboVNC may work with 32-bit-only operating systems, but we no longer claim that it does. This commit also removes the 32-bit Windows build from the AppVeyor script, since the previous commit broke it anyhow.
- Briefly describe each mode of operation under its associated syntax, since command-line users won't likely refer to the usage notes in the GUI or to the User's Guide. - "VncViewer" = "vncviewer", since the viewer is always invoked using its startup script these days. - Remove the "JVM:" text next to the JVM architecture. These days, the TurboVNC Viewer requires the TurboVNC Helper for full functionality. Thus, the viewer is effectively architecture-specific, and there is no distinction between the JVM architecture and the build architecture.
- Acknowledge 3.1.1 release. - Change version header to "3.2 Evolving" to clarify that the branch is an Evolving/Next-Gen code base (https://turbovnc.org/DeveloperInfo/Versioning).
... with the following exceptions: - Do not include Bouncy Castle algorithm implementations. (Require Java 16 instead.) This means that our JSch fork cannot currently support the chacha20-poly1305@openssh.com cipher, since the non-Bouncy-Castle implementation of that algorithm from JSch v0.1.71 and prior is not compatible with the current OpenSSH implementation. - Restore formatted comments nuked by the Maven formatter. - Do not include unused/unneeded code. - Restore public access to *.jzlib.JZlib and *.jzlib.ZStream. (NOTE: We should maybe revisit eliminating JZlib and using java.util.zip for everything, since we don't actually use SSH compression.) - Adapt the server-sig-algs implementation in mwiede/jsch@c17147c8 to better emulate the behavior of OpenSSH. (More specifically, OpenSSH only applies server-sig-algs to RSA keys: https://github.com/openssh/openssh-portable/blob/826483d51a9fee60703298bbf839d9ce37943474/sshconnect2.c#L1163-L1169.) Take the example of an SSH agent that offers 7 keys. The 7th key is the correct key to authenticate with a server, but that key uses a non-RSA algorithm (e.g. ssh-ed25519) that the server does not advertise in server-sig-algs. With MaxAuthTries=6, OpenSSH will fail to authenticate with that configuration by default, but it will succeed if the correct key is explicitly specified with the ssh -i option or the IdentityFile configuration keyword (because explicitly specifying the key promotes it to the head of the list.) JSch v0.1.66+ performs an initial authentication pass with only the algorithms advertised in server-sig-algs, then it performs a second pass with the other client-supported algorithms. With the aforementioned configuration, that behavior causes MaxAuthTries to be exceeded on the first pass (a fatal error), and the second pass never happens. Our implementation instead populates the existing Session.supportedRSAMethods list from the server-sig-algs message, if the server sent that message and the jsch.enable_server_sig_algs system property is enabled. This ensures that the client will not try any RSA algorithms except for those advertised in server-sig-algs. Note, however, that some OpenSSH server implementations still advertise ssh-rsa in server-sig-algs even if the algorithm is disabled in sshd_config. Functional and logging code from the following TurboVNC commits has been retained or adapted: 095c380 fb36f3b 053e754 dda0283 0a4aeb6 b632a9c 6838846 4a40896 273bfde fd34df2 ed50650 58986b7 dc2a88f d654a91 674e98c Completes #323
License note: UltraVNC v1.3.1 and later were/are made available under the GPL v3, which is not compatible with TurboVNC's license. However, the new TurboVNC Viewer toolbar icons are derived from icons in UltraVNC v1.2.4 (more specifically ultravnc/UltraVNC@3dd08c9e), which was made available under the GPL v2+.
Introduce a new turbovncserver.conf variable ($userDBus) and vncserver command-line option (-userdbus) corresponding to the TVNC_USERDBUS environment variable used by xstartup.turbovnc. This allows users to more easily enable the use of the per-user D-Bus session bus instance on a system-wide, per-user, or per-TurboVNC-session basis. The feature is still undocumented except in turbovncserver.conf and xstartup.turbovnc.
This allows users to easily modify certain aspects of JSch's behavior that aren't configurable using OpenSSH configuration keywords or TurboVNC Viewer parameters.
jsch.preferred_authentications now serves the same purpose.
Specifying the build worker image in the AppVeyor UI doesn't seem to work, and SignPath.io needs at least the Visual Studio 2017 image.
This is useful in conjunction with gdb or valgrind. Closes #448
(regression introduced by 0154936) If automatic desktop resizing is enabled and the TurboVNC Viewer is in windowed mode, recreating the viewer window in the body of CConn.resizeFramebuffer() sometimes causes the window's focusLost() method to be invoked. Under rare circumstances, the method can be invoked in the EDT while the RFB thread is still in the body of CConn.resizeFramebuffer(). Because of 0154936, CConnection.processMsg() (in the RFB thread) obtains a monitor lock on the CConnection/CConn instance, and the lock is still owned by the RFB thread when CConn.resizeFramebuffer() is called from CConnection.processMsg(). When the viewer window's focusLost() method attempted to call CConn.releasePressedKeys() in the EDT, CConn.releasePressedKeys() failed to obtain a monitor lock on the CConnection/CConn instance, and a deadlock occurred. It isn't actually necessary for CConn.releasePressedKeys() to obtain a monitor lock. That method is only ever executed in the EDT, and the resources it accesses are only ever accessed in the EDT. The monitor lock was in the original code base that the TurboVNC Viewer inherited from TigerVNC, but TigerVNC no longer has it. (The 'synchronized' keyword was silently removed in TigerVNC/tigervnc@e5b4003.) Fixes #447
There are some CConn methods that access the viewport object in the RFB
thread:
- setName(), setCursor(), enableGII(), giiDeviceCreated(),
enableQEMUExtKeyEventExt(), setLEDState()
* invoked when a specific type of RFB message is received from the VNC
server
- framebufferUpdateStart()
- framebufferUpdateEnd()
* if firstUpdate is set and the desktop resizing mode is not "Server"
- beginRect()
* if the RFB encoding has changed
There are also some CConn methods that re-create the viewport directly
in the EDT, as opposed to creating it in the RFB thread via
SwingUtilities.invokeAndWait():
- getOptions()
* if the toolbar is visible and "View only" was toggled in the Options
dialog
* if the viewer is in windowed mode and "Show toolbar" was toggled in
the Options dialog
* if the viewer is not in macOS full-screen mode and "Scaling factor"
was changed in the Options dialog
* if the viewer is not in macOS full-screen mode and "Remote desktop
size" was changed to something other than "Server" in the Options
dialog
* if the viewer is not in macOS full-screen mode and "Span mode" was
changed in the Options dialog
- zoomIn(), zoomOut(), zoom100(), toggleToolbar(), toggleFullScreen(),
toggleViewOnly()
In theory, if any operation from the first group coincides with any
operation from the second group, then the viewport object might be
accessed while it is being re-created. The specific issue I observed
was triggered by the following procedure:
- Run GLXSpheres with VirtualGL in a TurboVNC session.
- Pop up the TurboVNC Viewer Options dialog, choose a remote desktop
size that is larger than the client's screen, and click OK.
- Pop up the TurboVNC Viewer Options dialog, set the remote desktop size
to "Auto", and click OK.
Setting the remote desktop size to "Auto" causes CConn.getOptions() to
set firstUpdate, which causes CConn.framebufferUpdateEnd() to invoke
CConn.sendDesktopSize(), which invokes CConn.computeScreenLayout().
Since framebuffer updates were being received rapidly from the server,
it was highly likely (100% reproducible on my systems) that
CConn.computeScreenLayout() would be invoked before the new viewport was
visible, which triggered an IllegalComponentStateException when
CConn.computeScreenLayout() attempted to invoke
viewport.getContentPane().getLocationOnScreen().
Since all of the methods in the first group are guarded by the
CConn/CConnection monitor lock in CConnection.processMsg(), the solution
was to obtain a CConn/CConnection monitor lock for all invocations of
CConn.recreateViewport() in the second group. We already know that this
won't cause a deadlock, because in several places,
CConn.recreateViewport() is invoked via SwingUtilities.invokeAndWait()
(which causes it to execute in the EDT) while CConnection.processMsg()
owns the CConn/CConnection monitor lock. (However, note that this is
also the reason why we can't simply add a 'synchronized' keyword to
CConn.recreateViewport().)
The specific failure mode that I observed was by far the most likely
failure mode, since other possible failure modes would have required
very unfortuitous timing. It is also unknown whether other failure
modes would have triggered an exception or other visible problems. They
might have been silent, leading to unexpected but not necessarily fatal
behavior.
On recent versions of GNOME (v43 or v44 and later), and only on recent
versions of GNOME, our hackish method of obtaining the global JFrame
insets for X windows returns { 0, 0, 0, 0 }. This seems to be due to a
bug in the sun.awt.X11.XDecoratedPeer and sun.awt.X11.XWM classes that
causes the insets to be set from an invalid X11 property after they have
already been set from the _NET_FRAME_EXTENTS property. Fortunately, on
the affected window managers (and only on the affected window managers),
the cross-platform method of obtaining the global JFrame insets works.
On Fedora 40 and later, gnome-classic.desktop lives in /usr/share/wayland-sessions rather than /usr/share/xsessions.
This prevents the files from being overwritten when the package is upgraded.
- Document DRI3 extension usage and tradeoffs. - Document the process of choosing a window manager, including the relationship to session desktop files and the default behavior if no window manager is specified. Move the window manager compatibility documentation into this new section. - Move the documentation of 'vncserver -vgl'/$useVGL into a separate section under "Using VirtualGL on a TurboVNC Host." Expand that documentation to include notes about disabling or reconfiguring VirtualGL for a specific 3D application, since that question comes up frequently. - Unmention the libglvnd requirement for the TurboVNC Server's software GLX/OpenGL implementation. All supported platforms now have libglvnd-enabled builds of Mesa.
xstartup.turbovnc in TurboVNC 3.1.x executed /etc/X11/xinit/xinitrc if no window manager was specified and gnome.desktop and ubuntu.desktop could not be found. On most supported platforms, /etc/X11/xinit/xinitrc runs GNOME, but that is not the case with the Ubuntu MATE and Xubuntu flavors. Because of 716abdd, xstartup.turbovnc no longer falls back to xinitrc at all, because recent Linux distributions no longer fully support xinitrc. (As an example, starting the window manager via xinitrc on Ubuntu 24.04 can cause the window manager in a TurboVNC session to abort when a user logs out of a local session.) There unfortunately isn't a reliable cross-platform way to detect the default window manager. xinitrc on Ubuntu seems to use /etc/alternatives/x-session-manager and /etc/alternatives/x-window-manager, in that order. Hypothetically, xstartup.turbovnc could read those links and try to match them to a session desktop file, but that mechanism would be very system-specific, error-prone and non-robust (since it would be necessary to specifically handle each window manager), and future-prone (since we have no idea whether those links represent a stable interface.) Since MATE and Xfce are officially supported window managers (https://turbovnc.org/Documentation/OSSupport), the easiest solution is simply to add them to the fallback hierarchy if no window manager is specified. Inevitably, someone will complain that other window managers aren't also in the fallback hierarchy, but we have to draw the line somewhere. (A documented official support policy is at least a reasonable and defensible position.) Fixes #453
... for a session desktop file corresponding to the specified window manager. This is a more generic solution than b717203 and reflects the fact that there is nothing Wayland-specific about the session desktop files under /usr/share/wayland-sessions. This future-proofs xstartup.turbovnc against the possibility that other session desktop files will be moved into /usr/share/wayland-sessions.
- Use strict code signing verification.
- Retarget the symlinks under
TurboVNC Viewer.app/Contents/PlugIns/jre/Contents/Home/legal/
so that strict code signing verification passes.
- Explicitly sign
TurboVNC Viewer.app/Contents/Resources/Native/libturbovnchelper.dylib
('codesign --deep' skips it.)
- Overwrite the existing signatures on the JRE components.
- Enable the hardened runtime with the com.apple.security.cs.allow-jit
entitlement.
- Use 'cp -Rp' rather than 'cp -RX' to copy the .app bundles, in order
to preserve the code signing information. (I'm not sure why 'cp -RX'
was used. It was introduced in
23cc965 without comment.)
This is necessary in order to notarize the application and also to build it on modern macOS platforms. Since the Adoptium build of OpenJDK 21 requires macOS 10.12 or later, this does not affect the TurboVNC Viewer's system requirements. I also took the opportunity to revisit #350, including poring over the macOS 10.14 SDK change log and trying to manually reverse any changes to the Cocoa application defaults that landed in that SDK. The cause of the issue unfortunately remains a mystery, which means that it cannot currently be solved or worked around on Apple Silicon platforms. In the long term, it may be necessary to work around it by implementing a full- screen mode that doesn't use Spaces, a la TigerVNC or VLC, and either abandoning the Spaces-based full-screen mode or retaining it as a non-default option that doesn't support multi-screen spanning.
Print a more instructive error message if a remote desktop resize fails because the viewer authenticated using view-only credentials.
Using an external SSH client with the TurboVNC Session Manager is not officially documented. However, it works with the caveat that the external SSH client is only used for the final VNC connection. (The built-in SSH client is still used for session management.) ae1c3fa introduced a regression whereby, when attempting to use ExtSSH with the TurboVNC Session Manager, the viewer used the Via command-line template by default instead of the Tunnel command-line template, which failed because no gateway host had been specified.
TurboVNC 3.1.x and prior provided a 32-bit Windows package with ISS AppName "TurboVNC" and a 64-bit Windows package with ISS AppName "TurboVNC 64-bit". TurboVNC 3.2 removed 32-bit Windows support (61b896c) and changed the ISS AppName to "TurboVNC". This created an issue whereby, if an older 64-bit version of TurboVNC was installed on the system, installing TurboVNC 3.2 resulted in: - two installer registry entries ("TurboVNC 64-bit" for the old version and "TurboVNC" for the new version) in "Settings > Apps > Installed apps" or "Settings > Apps > Apps & features" - a single install folder (c:\Program Files\TurboVNC) containing all of the files from the new version and any files (including the uninstaller) that were unique to the old version - two Start Menu groups ("TurboVNC 64-bit" for the old version and "TurboVNC" for the new version) This was mostly innocuous, because: - The files in c:\Program Files\TurboVNC were still upgraded, as expected. - Windows hid all of the links in the old "TurboVNC 64-bit" Start Menu group that were shared with the new version. (When upgrading from TurboVNC 3.0.x+, only the uninstall link was visible in the "TurboVNC 64-bit" Start Menu group on Windows 10, and the entire group was hidden on Windows 11.) - Uninstalling the old version left the "TurboVNC" Start Menu group and any files (including the uninstaller) that were unique to the new version. (When upgrading from TurboVNC 3.0.x+, none of the links except for the uninstall link continued to work.) Subsequently uninstalling the new version cleaned up those items. - Uninstalling the new version left the "TurboVNC 64-bit" Start Menu group and any files (including the uninstaller) that were unique to the old version. (When upgrading from TurboVNC 3.0.x+, none of the links except for the uninstall link continued to work.) Subsequently uninstalling the old version cleaned up those items. Similarly, if an older 32-bit version of TurboVNC was installed on the system, installing TurboVNC 3.2 resulted in: - a single "TurboVNC v3.2" installer registry entry - two install folders (c:\Program Files (x86)\TurboVNC for the old version and c:\Program Files\TurboVNC for the new version) - a single "TurboVNC" Start Menu group containing all of the links from the new version and any links (including the uninstall link) that were unique to the old version This was mostly innocuous, because: - The links in "TurboVNC" were still upgraded, as expected. - Uninstalling the new version left the c:\Program Files (x86)\TurboVNC folder and any links (including the uninstall link) that were unique to the old version. (When upgrading from TurboVNC 3.0.x+, the entire Start Menu group was removed.) The installer registry entry for the old version was restored. Subsequently uninstalling the old version removed the c:\Program Files (x86)\TurboVNC folder and any remaining links. This commit modifies the installer so that: 1. It now looks for an installation of "TurboVNC 64-bit" or a 32-bit installation of "TurboVNC" and automatically uninstalls it if it is installed. 2. It refuses to install on 32-bit-only Windows systems. (Because the installer itself is a 32-bit Windows executable, it previously allowed the 64-bit TurboVNC Viewer to be installed on 32-bit-only Windows systems, although the viewer subsequently failed to launch.) 3. It installs TurboVNC like a 64-bit application rather than a 32-bit application on Windows/Arm. Additional Windows/Arm subtleties: - Previous versions of TurboVNC were installed like 32-bit applications on Windows/Arm. Thus, upgrading them to TurboVNC 3.2 always resulted in a single install folder (c:\Program Files (x86)\TurboVNC) containing all of the files from the new version and any files (including the uninstaller) that were unique to the old version. - To prevent a similar issue to the aforementioned issue that occurred when upgrading a 32-bit version of TurboVNC to TurboVNC 3.2, the installer now uninstalls TurboVNC 3.2 beta1 or 3.2 on Windows/Arm.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not su
2E67
pported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )