KRDC vnc client not connecting to servers since this update

[baaann]

I have an X2go server that we have used to connect to local windows desktops over vnc via krdc and this has worked consistently for years.
Since this weeks updates KRDC will no longer connect to any of the local desktops giving the message
"Authentication failed. Please try again"
This is either via Kwallet integration or manually entering the passwords.
Launched via Konsole the only extra feedback is "KRDC: rfbInitClient failed"
The X2go desktop in use is Lxqt, although I have tried it on an openbox session as well.
Google did not throw up any recent issues, but suggested libvncserver may be to blame and although I couldn't backtrack versions, upon resyncing there was an update available which I installed without making any difference to the connection problem
I have not changed any USE flags and cannot see any obvious system changes that could have impacted it. I have run out of ideas and if anyone has any suggestions they will be mos welcome?

[asturm]

What is "this update"? Does your system accept arch or ~arch KEYWORDS? What version of krdc did you have previously installed, which one do you have now? Notice there are currently two versions available in Portage.

Notice there is already at least one report for a much older version of krdc upstream: https://bugs.kde.org/show_bug.cgi?id=454036

[baaann]

Thanks for the quick reply Asturm and yes I was remiss in my detail, apologies my gentoo has been pretty much on auto pilot in recent years

[giro83]

Have you fixed your issue yet?

libvncserver is broken for me after a world update yesterday. I fixed my issue by compiling libvncserver with use flag gcrypt (Use dev-libs/libgcrypt as crypto backend). Can you try the same please?

My research so far (I haven't filed a bug yet because I haven't reached RCA yet):



Following a world update, my usual/unchanged vnc client could no longer connect to my x11vnc server on Gentoo. My /etc/x11vnc.pass file did not change throughout this update. The x11vnc log file reported:

14/01/2023 00:02:51 rfbProcessClientSecurityType: executing handler for type 2
14/01/2023 00:02:51 Couldn't read password file: /etc/x11vnc.pass
14/01/2023 00:02:51 rfbAuthProcessClientMessage: password check failed
14/01/2023 00:02:51 rfbClientSendString("password check failed!")

Please note these errors do not strictly mean the file couldn't be accessed, they can mean its contents could not be processed (see source code for libvncserver).

The first thing I noticed is that "x11vnc -storepasswd /etc/x11vnc.pass" no longer worked as intended. Although running the command returned no errors, the password saved in /etc/x11vnc.pass was *NOT* encrypted.

For convenience, here I will say encrypted, but I know the term encrypted is inaccurate (from `man x11vnc`: "...it is NOT encrypted, only obscured with a fixed key...").

Had a look at the source code: x11vnc.c calls store_homedir_passwd(), which calls rfbEncryptAndStorePasswd() in common/vncauth.c (in the lib), which calls encrypt_rfbdes() (again in the lib).

Now, encrypt_rfbdes() does encryption in-place, in the sense 'unsigned char encryptedPasswd[8];' is both used as 'in' and 'out' parameter to encrypt_rfbdes().

This explains my failure of ending up with a clear text password in /etc/x11vnc.pass. It doesn't explain though why the different functions fail to report an error to each other and, ultimately, to the user.

Now... encrypt_rfbdes() exists in many versions in different source files. My problem went away when I enabled use flag gcrypt (Use dev-libs/libgcrypt as crypto backend) for libvncserver.

I assume this will reproduce on my system if I revert the flag. I was short on time tonight, so I could not attach gdb to x11vnc to see where the failure is. The lack of error detection and reporting is concerning.

My versions are:
net-libs/libvncserver-0.9.14 (this is ~amd64)
x11-misc/x11vnc-0.9.16-r7

But I downgraded libvncserver to stable and the issue remained.

[baaann]

Sorry for the late response.

I eventually tried removing the passwords from the windows vnc clients and that allowed connection, so I had established that it was a password issue on the server. Unfortunately life got busy and I didn't get back to the issue until now.

As suggested, I have recompiled libvncserver with the USE="gcrypt" and passwords are again accepted, so many thanks for your post

[baaann]

I have posted the following bug
https://bugs.gentoo.org/show_bug.cgi?id=893608

[asturm]

[baaann]

[asturm]

Yes, that part is clear:

[baaann]

[asturm]

Please check back in the bug you filed.

[deezel]

[asturm]

libvncserver got a fix, please do test: https://bugs.gentoo.org/893608