[Regression] PR #1311 still selects Apple VNC auth after banner normalization

[neooriginal]

Title

PR #1311 still selects Apple VNC auth after banner normalization

Platform

Website - Chrome

Server Installation Method

Docker

Version

2.7.1 with merged Termix-SSH/Termix#1311 (dev-2.8.0)

CLI Installation Method

N/A

CLI Version

N/A

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have checked open issues and ensured this is not a duplicate

The Problem

Termix-SSH/Termix#1311 correctly normalizes Apple's private RFB 003.889 banner to RFB 003.008, but macOS then advertises security types 30,33,36,2,35. The compatibility proxy forwards that list unchanged, so guacd/libvncclient still selects Apple Remote Desktop authentication (30) before classic VNC password authentication (2). With a dedicated VNC viewer password and no username, the VNC child exits and the UI remains on “Connecting to VNC session...”.

This is the unresolved security-negotiation portion already documented in #1015. The new regression detail is that the merged banner proxy in Termix-SSH/Termix#1311 provides a place where Termix can safely constrain the advertised list, but currently does not do so.

A verified follow-up fix is available in Termix-SSH/Termix#1313. It filters the Apple security list to classic VNC authentication (type 2) only when type 2 is actually offered, while preserving standard RFB servers and Apple servers without type 2.

How to Reproduce

1. Run the Docker deployment with the dev-2.8.0 code containing fix: support macOS VNC connections Termix#1311 and guacd 1.6.0.
2. Configure a macOS Screen Sharing target with “VNC viewers may control screen with password” enabled.
3. Configure the Termix VNC connection with no username and the dedicated VNC password.
4. Connect through the web client.
5. Observe that the compatibility proxy is established but guacd selects/fails on Apple security type 30, or the UI remains stuck connecting.

Expected Behavior

When macOS offers classic VNC password authentication (type 2) for a username-less connection, the compatibility proxy should advertise only type 2 to guacd and allow the session to complete.

Actual Behavior

The banner is normalized, but the original list 30,33,36,2,35 is forwarded. libvncclient chooses type 30 and the connection does not complete.

Verification of Proposed Fix

Termix-SSH/Termix#1313 was tested with:

• Three proxy regression tests, including fragmented Apple negotiation and standard-server pass-through.
• ESLint and repository-wide TypeScript type checking.
• A production Docker build.
• A real end-to-end path: Termix web client → guacd 1.6.0 → compatibility proxy → macOS Screen Sharing. Authentication completed and the actual macOS lock screen rendered in the browser.

Additional Context

• Original related report: [BUG] VNC connection to macOS Screen Sharing fails after selecting Apple security type 30 #1015
• Earlier regression report closed by #1311: [Regression] VNC to macOS Tahoe still fails during RFB 003.889 handshake in Termix 2.7.1 #1206
• Incomplete merged fix: fix: support macOS VNC connections Termix#1311
• Verified follow-up PR: fix: force classic auth for macOS VNC Termix#1313

[termix-triage-bot]

Auto-triage

VNC connections to macOS Screen Sharing fail after PR #1311 because the compatibility proxy forwards an unfiltered list of security types, leading to incorrect authentication method selection. A verified fix is available in PR #1313.

Field	Value
Type	Bug
Difficulty	2/5 (Small)
Priority	Urgent
Labels	bug rdp-vnc platform-web platform-docker platform-macos good-first-issue

A maintainer will review shortly. If the auto-classification looks wrong, feel free to say so.

[neooriginal]

Fixed in Termix-SSH/Termix#1313

[termix-triage-bot]

It looks like this issue may be resolved based on the comments.

Based on the thread, the fix was: The original poster confirmed the issue is fixed in Termix-SSH/Termix#1313.

If that's correct, feel free to close it. If the problem is still happening, please drop a comment with your current Termix version and any new info.

[neooriginal]

It looks like this issue may be resolved based on the comments.

Based on the thread, the fix was: The original poster confirmed the issue is fixed in Termix-SSH/Termix#1313.

If that's correct, feel free to close it. If the problem is still happening, please drop a comment with your current Termix version and any new info.

Once my PR is merged it will be solved