vino won't accept my password

same here on both my x86 and AMD x64 boxes.
I'm wondering if a complete removal + reinstall would fix it?

@Jaakan: I don't think a reinstall would help. I tried it with a completely fresh install...

Changing the password makes it work again.

This is weird, today, I did a dist-upgrade again and the password was rejected again. I had to set it again to be able to connect. This time was an update from Wednesday's Edgy to today's Edgy.

weird, vino has not changed for some time

I also have the same problem. Fresh edgy installation. With dapper no problems.

Finally I remove the vino package with purge option. Now it works perfect. I will restart system tomorrow to see if everything is ok.

I encounter the same bug.
After an upgrade from dapper to edgy, vino don't accept my password.
To be precise, it seems it worked after the upgrade for something like one week and then it stopped, maybe after an update, but not sure
I tried changing it with vino-preferences, didn't solved.
I then removed and purged vino, reinstalled, still didn't worked.
I then generated a password from command line and changed the password within gconf-editor and it worked.

I encountered this bug on an account I used to vnc to when I was in dapper, but that bug didn't happen on antoher user on the same system that didn't used vnc when the system was running dapper.

Also, I cannot reproduce this bug on an installed edgy system (not upgraded from dapper).

I wasn't able to reproduce the bug

several people have the issue, marking as confirmed

I think the problem is on line 309 of vino-prefs.c. The password strings is g_free'd (and I don't think it should be). This would explain it not working when the server starts, but working when the password changes (where the prefs dialog updates the server directly instead of using the loaded prefs).

I'll be testing a fix shortly...

Too late for official edgy release, but this should be in the security updates for edgy after it goes out.

Thank you for looking at that Kees. That's what upstream did too: http://cvs.gnome.org/viewcvs/vino/server/vino-prefs.c?r1=1.2&r2=1.3

I'm not sure if that's a security issue or should go to edgy-proposed,edgy-updates rather

I've sent email to pitti to see what he thinks. :)

Doesn't sound like a vulnerability to me, but of course it's a grave bug in vino which should be fixed in -updates.

Okay, let's see if I can get through my first SRU. :)

Impact: Anyone who has configured vino (Remote Desktop) to use a password must re-set the password at the start of every desktop session. (The password is lost by vino after being loaded from gconf.) This greatly reduces the utility of Remote Desktop access, and is a regression from Dapper.

Fix: One line correction, which matches upstream's solution for the same problem. (See above for cvs commit URL.)

Patch: See attached debdiff, which uses the proposed pocket.

OK for -proposed

Format: 1.7
Date: Tue, 24 Oct 2006 16:02:41 -0700
Source: vino
Binary: vino
Architecture: source
Version: 2.16.0-0ubuntu2.1
Distribution: edgy-proposed
Urgency: low
Maintainer: Jordi Mallach <email address hidden>
Changed-By: Kees Cook <email address hidden>
Description:
 vino - VNC server for GNOME
Changes:
 vino (2.16.0-0ubuntu2.1) edgy-proposed; urgency=low
 .
   * debian/patches/01_fix_password_free.patch:
     - don't g_free vnc server password at all (Ubuntu: #65795)
Files:
 6877e33ff4b97a4c4b79eba7046e3a69 1548 gnome optional vino_2.16.0-0ubuntu2.1.dsc
 fa62d4c765eaf03e6200debceeee2992 3512 gnome optional vino_2.16.0-0ubuntu2.1.diff.gz

I have tried a known working (on dapper) %gconf.xml file.

I have also tried one known to be working on Edgy, apparently.

I still get authentication error.

I have also build from source and modified vino_config.c and commented line 309 [ g_free (vino_vnc_password); ], and replaced stock vino with this. Still no luck, even after reboot!

I am connecting through an SSH tunnel if that makes any difference. TightVNC Viewer (windows) -> putty (5900 -> l:5900) -> vino.

Would appreciate it if anyone has a work-around for the time being or anything! I need to connect to my machine.

-Kev-

kevb, just to confirm our chat on #ubuntu, you said you were able to build a new vino package with the proposed debdiff, and after that, things worked okay, correct?

Yep, I patched the source with the debdiff posted above. After rebooting the problem has been corrected.

In case anyone else is stuck like me untill the update is released, here are the commands Kees kindly gave me to patch the source (slightly modified):

cd /tmp
apt-get source vino
wget http://librarian.launchpad.net/4941195/vino_2.16.0-0ubuntu2.1.dsc.debdiff
cd vino-*
patch -p1 < /tmp/vino_2.16.0-0ubuntu2.1.dsc.debdiff
debuild -uc -us

#Then to install:
sudo dpkg -i ../vino*.deb

Of course it's probably recommended that you wait for the update, but in my case I needed vino working and it sounded like this was a simple fix. Thanks for the help from Kees Cook & #ubuntu (irc.freenode.net).

-Kev-

As a word of caution, you may need some other packages installed before that will work. I wrote up a quick wiki page about it:

https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff

Thanks for the fix Kees! It worked perfectly for me.
Now if I could just get a similar fix for bug# 67189 and I would be all set with Edgy.

That upload fixes the issue:

 vino (2.17.2-0ubuntu1) feisty; urgency=low
 .
   * New upstream version:
     Features:
     - Add "local_only" GConf key for use with SSH tunnels (Ubuntu: #54312)
     - Add "alternative_port" GConf key
     - Add ability to use gnome-keyring to store VNC password
     - Add IPv6 support
     Fixes:
     - Update for RFB 3.8
     - Fix for X servers which don't support XShm (Ubuntu: #32641)
     - Fix CoRRE encoding problem
     - Back-port some fixes from upstream libvncserver
     - Add GTK category to .desktop file
     - Mark some weird glade strings as non-translatable
     - Fix icons not changing when icon theme changes
     - Use glib's base64 functions instead of our own
     - Use GtkLinkButton instead of VinoURL
   * debian/control.in:
     - updated Build-Depends according to configure
   * debian/patches/01_fix_password_free.patch:
     - fixed correctly by the new version (Ubuntu: #65795)

This *is* a security bug - if vino authenticated the user using free password area instead of a real password, an attacker might predict what will be the content of the freed memory area, use it as the authentication password, and gain unauthorized access to the VNC server, without having to guess the user password!
Will you please upload a security fix?

How can I install this package in edgy?. I don't find in repos:

Format: 1.7
Date: Tue, 24 Oct 2006 16:02:41 -0700
Source: vino
Binary: vino
Architecture: source
Version: 2.16.0-0ubuntu2.1
Distribution: edgy-proposed
Urgency: low
Maintainer: Jordi Mallach <email address hidden>
Changed-By: Kees Cook <email address hidden>
Description:
 vino - VNC server for GNOME
Changes:
 vino (2.16.0-0ubuntu2.1) edgy-proposed; urgency=low
 .
   * debian/patches/01_fix_password_free.patch:
     - don't g_free vnc server password at all (Ubuntu: #65795)
Files:
 6877e33ff4b97a4c4b79eba7046e3a69 1548 gnome optional vino_2.16.0-0ubuntu2.1.dsc
 fa62d4c765eaf03e6200debceeee2992 3512 gnome optional vino_2.16.0-0ubuntu2.1.diff.gz

Hello,

I agree with a security bug. It would be fixed quickly.

Best regards.

archive admins, any progress on this? This is still waiting in the queues even though it has been approved by mdz... is there anything I can do to help it along?

Accepted into edgy-proposed (sorry for the delay; all stable release updates were on hold during the UDS and allhands meetings). Per StableReleaseUpdates, once this has built, please notify the QA team via Simon to verify that the bug has been fixed and that there are no regressions, and test it yourself.

This has been tested to fix the bug and I cannot find any regressions in vino's functionality.

Good to go into -updates.

I have uploaded 2.16.0-0ubuntu2.2 for -updates since (more than) a week has now passed without any negative issues.

As I understand, this completes step 5 of the SRU.

Upload verified and accepted for edgy-updates.