GNOME Bugzilla – Bug 499841
tomboy problems communicating with gnome keyring
Last modified: 2009-04-23 02:14:01 UTC
Please describe the problem: It looks like when running tomboy and trying to use the webdav synchronization mechanism there is a problem communicating with the gnome keyring under fedora 8. I am able to manually mount my webdav filesystem with wdfs. However when trying to use tomboy for synchronization I get the following error: Error connecting :( Saving configuration to the GNOME keyring failed with the following message: Unknown error There is also no .tomboy.log in my home directory. Steps to reproduce: 1. Open tomboy preferences dialog 2. Insert server options for wdfs fuse synchronization module 3. click save Actual results: I get the error message : Error connecting :( Saving configuration to the GNOME keyring failed with the following message: Unknown error Expected results: Should successfully talk to the gnome keyring. Does this happen every time? Yes. Other information:
I saw this while using a Fedora 8 test build, and I thought I reported it somewhere but I can't find any bug numbers. It seems to be specific to Fedora 8. I remember discussing it with Alp Toker so I'll ping him and see if he has any additional information. It's not a Tomboy bug (either Fedora, gnome-keyring, or gnome-keyring-sharp, I think), but I'll leave this open for now until I figure out where to redirect it. Thanks for the report!
We could mark this as an enhancement bug saying that Tomboy should support webdav authentication even in the absence of the GNOME keyring. I guess the question then is whether or not we should do any password storage in that scenario.
same problem on gentoo with tomboy-0.8.1 and gnome-keyring-2.20.2
(In reply to comment #3) > same problem on gentoo with tomboy-0.8.1 and gnome-keyring-2.20.2 Do you have selinux enabled?
(In reply to comment #4) > (In reply to comment #3) > > same problem on gentoo with tomboy-0.8.1 and gnome-keyring-2.20.2 > > Do you have selinux enabled? > Yes I have selinux enabled.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > same problem on gentoo with tomboy-0.8.1 and gnome-keyring-2.20.2 > > > > Do you have selinux enabled? > > > > Yes I have selinux enabled. > I have verified that selinux is not the issue. I rebooted my home machine with selinux=0 and am still seeing the same error.
i do *not* have selinux here. and the same happens.
maybe some more info would help. here is my portage --info. i tested it on 2 64bit systems with the same result. Portage 2.1.3.19 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.7-r0, 2.6.23-gentoo-r1debug x86_64) ================================================================= System uname: 2.6.23-gentoo-r1debug x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Timestamp of tree: Mon, 26 Nov 2007 21:30:07 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r5, 2.5.1-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LINGUAS="de hu en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/local/portage-overlays/my" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 amr audiofile bash-completion berkdb bitmap-fonts bzip2 cairo cddb cdr cli cracklib crypt cups dbus dia directfb doc dri dv dvd dvdr emacs encode exif fbcon ffmpeg firefox flac foomaticdb fortran fuse gdbm gif gnome gtk gtk2 hal hbci hfs httpd ical iconv insecure-drivers ipv6 isdnlog jack jpeg ladspa lame libnotify libsamplerate live logrotate makecheck matroska midi mmx mmxext mod mono mozsvg mp3 mpeg mudflap musicbrainz ncurses network nls nptl nptlonly nsplugin ogg opengl openmp pam pcmcia pcre pda pdf perl pic png postscript ppds pppd python qt3support quicktime readline reflection samba sdl session shout spell spl sse sse2 ssl stream svg tcpd theora threads thunderbird truetype truetype-fonts type1-fonts unicode usb vcd vlm vorbis wmf wmp x264 xml xorg xv xvid yv12 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" CAMERAS="kodak ptp2" ELIBC="glibc" INPUT_DEVICES="keyboard ps2mouse mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de hu en" USERLAND="GNU" VIDEO_CARDS="dummy fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS mono-1.2.5.1-r1
same here on Debian Sid. If I recall correctly, I saw similar probs on OpenSUSe
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
I have this problem without selinux, and on any linux distribution I have tested so far, including the latest Ubuntu, Debian and SuSE. Please someone change the status from "Unconfirmed" to "new", as we all see how many people are seeing this problem
This error shows up on debian ( lenny ): 29/05/2008 21.20.42 [WARN]: Getting configuration from the GNOME keyring failed with the following message: Unknown error Please change status to new! Thanks
Created attachment 113463 [details] [review] The patch for Tomboy/Gnome.Keyring/ResultCode.cs The sole change is that missing value, NoMatch is added.
I can confirm this bug on Ubuntu 8.04. The configuration is the following: uname -a: Linux axe-desktop 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux GNOME version: 2.22.2 (built on 03.06.2008 by Ubuntu) Tomboy version: 0.10.2 mono --version: Mono JIT compiler version 1.2.6 (tarball) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none When setting the parameters for WebDAV synchronisation login, I get "Getting configuration from the GNOME keyring failed with the following message: Unknown error" message in .tomboy.log, and saving the settings fails with the message "Saving configuration to the GNOME keyring failed with the following message: Unknown error". I downloaded the source code of Tomboy 0.10.2 and tried to find out, what was the reason for this error. It appeared that GNOME keyring returned the result code "9" for Find operation, and Tomboy code did not know how to interpret this value, thus throwing "Unknown error" exception. I've looked into GNOME documentation for GNOME keyring API (http://library.gnome.org/devel/gnome-keyring/stable/gnome-keyring-gnome-keyring-result.html#GnomeKeyringResult) and saw that result codes are described by the following enum: typedef enum { GNOME_KEYRING_RESULT_OK, GNOME_KEYRING_RESULT_DENIED, GNOME_KEYRING_RESULT_NO_KEYRING_DAEMON, GNOME_KEYRING_RESULT_ALREADY_UNLOCKED, GNOME_KEYRING_RESULT_NO_SUCH_KEYRING, GNOME_KEYRING_RESULT_BAD_ARGUMENTS, GNOME_KEYRING_RESULT_IO_ERROR, GNOME_KEYRING_RESULT_CANCELLED, GNOME_KEYRING_RESULT_KEYRING_ALREADY_EXISTS, GNOME_KEYRING_RESULT_NO_MATCH } GnomeKeyringResult; Comparing this declaration to the similar one in Tomboy code (Gnome.Keyring.ResultCode enum, defined in Tomboy/Gnome.Keyring/ResultCode.cs): public enum ResultCode { Ok, Denied, NoKeyringDaemon, AlreadyUnlocked, NoSuchKeyring, BadArguments, IOError, Cancelled, AlreadyExists } one can see that the value NO_MATCH (ordinal 9) isn't present in Tomboy's ResultCode enumeration. So the scenario that reproduces the bug is the following: When showing the dialog page with WebDAV sychronization parameters, Tomboy tries to find the WebDAV credentials in GNOME keyring. If they aren't present there (and that's also the case when the WebDAV sychronization is set up for the first time), GNOME keyring returns NO_MATCH value, meaning "No such item is present in the keyring". Tomboy is unable to interpret the result code, since it's not present in Gnome.Keyring.ResultCode enum, and throws KeyringException with "Unknown error" message. When saving the credentials to the keyring, it calls the Find() operation again in order to determine, whether it should create a new keyring item or update the existing one. So the Find() operation throws again, and "Saving.... failed.." dialog box is shown. Having found out this, I've prepared the patch that fixes the bug. The patch consists of two changes: 1) The value NoMatch (ordinal value 9) is added to Gnome.Keyring.ResultCode enumeration. 2) The Find() and FindNetworkPassword() methods of Gnome.Keyring.Ring class are made to return empty result, if the underlying SendRequest() method throws KeyringException with NoMatch result code. Attached are two *.diff files containing the fixes I've made. I've also attached the patched files, Ring.cs and ResultCode.cs. I could not find out directly, why this discrepancy in result codes appeared. However I assume this value, NO_MATCH, has been added recently (perhaps, in GNOME 2.22.2, because the bug is not reproducible on Ubuntu 7.10, GNOME 2.20), and Tomboy code wasn't updated accordingly. Please review the fix I made, and apply it if it's feasible. I'd be also glad if my finds helped you fixing this bug in other distributions, except Ubuntu.
Created attachment 113464 [details] [review] The Ring methods updated to interpret NoMatch result code correctly
Created attachment 113465 [details] The patched ResultCode.cs file I also attach the patched version of ResultCode.cs, in case anything goes wrong with the provided patch.
Created attachment 113466 [details] The patched Ring.cs fie I also attach the patched version of Ring.cs, in case anything goes wrong with the provided patch.
Alexey, you are awesome! I'll make sure this gets to the upstream gnome-keyring-sharp, too. I still need to double-check that this is valid for all supported gnome-keyring versions (but I think this fix wouldn't break old versions, anyway). Hopefully I'll get to it today... BTW, it's generally easier (for us) if you get the source from SVN (releases are tagged so you can get whatever version you want), and then generate patches using `svn diff > mychange.patch`. Don't worry about it for this one, but keep it in mind for the future.
I'm glad to help make a good application even better :) Unortunately I haven't found your Wiki page on submitting patches prior to writing here; otherwise I would have done it in the most convenient way for you. If I have another occaison to help improve Tomboy in the future, I'll surely make a patch using svn.
Note to self: review this and get it committed. And make sure to talk to alp (upstream).
Committed in r2137. Thanks again Alexey! Still need to talk to Alp about getting it fixed upstream.
Fixed upstream, now.