No Matching Security Types

[gitcnd]

Cannot connect to 50% of VNC servers out there - e.g. the default Raspberry Pi one etc.
This is not hard to fix - you just have to want to fix it.
Keep in mind that "None" is one of your offered security options, so, you cannot use "security" as any excuse not to fix this bug...

[bphinz]

Cannot connect to 50% of VNC servers out there - e.g. the default Raspberry Pi one etc.

Raspberry Pi OS ships with RealVNC server which by default uses a proprietary authentication.

[gitcnd]

I said "Security Types", not authentication.

[bphinz]

And their default security type uses an undisclosed/proprietary protocol

On Sun, Jul 11, 2021 at 7:06 PM Chris Drake ***@***.***> wrote: I said "Security Types", not authentication. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45M3LW6L3DAGMNUSYHVELTXIPWNANCNFSM5AFIK7YA> .

-- Sent from Gmail Mobile

[gitcnd]

Nope. Here is the source code for it: https://archive.realvnc.com/download/get/785/eula/
And it is GPL

[gitcnd]

Not to mention - RealVNC wrote the VNC RFC in the first place, so calling that "undisclosed/proprietary" seems unlikely
https://datatracker.ietf.org/doc/html/rfc6143

[bphinz]

Yes, they wrote the RFC for the RFB protocol, but nowhere did they ever disclose the details of their security types. This is roughly the equivalent of complaining to your honda dealer that a ford key fob can’t be used to unlock your car. If you want to use any other non-RealVNC client with a RealVNC server, you cannot use their proprietary security types. Reconfigure the server to use one of the security types that we can support. If you google the issue in question you will find dozens of explanations and I’m sure instructions for configuring their server.

On Sun, Jul 11, 2021 at 7:31 PM Chris Drake ***@***.***> wrote: Not to mention - RealVNC *wrote* the VNC RFC in the first place, so calling that "undisclosed/proprietary" seems unlikely https://datatracker.ietf.org/doc/html/rfc6143 — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45M3OX7FGEW5BZPAA5Z7DTXISVHANCNFSM5AFIK7YA> .

-- Sent from Gmail Mobile

[gitcnd]

... or you could just fix your bug*.

Their source code is RIGHT THERE, and it's OPEN SOURCE.

• Yes it's a bug - your code deos not work with a huge number of products out-of-the-box - that's your fault, not those products, and it's crazy to expect millions of users to waste hours trying to reconfigure their default settings because you're too stubborn to copy/paste the solution form the open source they provide.

[CendioOssman]

I'm afraid that's the source for version 4 of their product. Everything they've done in the ten years after that is completely secret. We'd love to support their extensions so we could be compatible, but trying to reverse engineer them is not something we have the resources for.

At this point the most productive way forward is that you, as a user, complain to RealVNC that their secrecy around their protocols extensions are making their product more difficult to use. If they produce documentation for their security types then we can look at getting those supported in TigerVNC. Until then things are unlikely to change.