gnome-keyring-sharp uses deprecated socket interface; apps cannot use keyring

[deichschuh]

Binary package hint: mono

In the mono application docky, there is a gmail-checker, in Ubuntu Lucid, it is unable to connect to gnome-keyring, see Bug 529080 for this. In the bug report it is said that this is a mono problem.

ProblemType: Bug
Architecture: amd64
Date: Wed Mar 10 14:37:28 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
Package: mono-runtime 2.4.4~svn151842-1ubuntu2
ProcEnviron:
 LANG=de_DE.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: mono
Uname: Linux 2.6.32-16-generic x86_64

[directhex (directhex)]

gnome-keyring-sharp no longer functions, due to incompatible changes to gnome-keyring's previously stable API/ABI.

[directhex (directhex)]

Seems the killer change is the removal of the gnome-keyring-daemon socket interface.

[directhex (directhex)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.348.0 Safari/533.2

gnome-keyring no longer offers a socket interface, as per this commit:

commit da22a40250da283a502ecb35add5e6548c654c6b
Author: Stef Walter <email address hidden>
Date: 2009-12-17

    Remove old keyring socket, library and code support.

    After this commit, all callers must use the libgnome-keyring module
    to access secrets. The old socket method and included library
    no longer work.

As gnome-keyring-sharp is entirely dependent upon a socket connection, it is now no longer usable on GNOME 2.30+

Reproducible: Always

Steps to Reproduce:
1. Use Gnome 2.30
Actual Results:
Binding fails to find g-k-d

Expected Results:
Functionality

[Chris Halse Rogers (raof)]

Marking as critical in gnome-keyring-sharp; this renders the package entirely useless.

[James P Michels III (james-p-michels)]

What is the fix here? Write a new wrapper to pInvoke into the c lib?

Is anyone working on a new wrapper?

[directhex (directhex)]

Yeah, that's the fix. I spoke briefly with Gonzalo Paniagua Javier on IRC, the original author of g-k-s, who implied he had no immediate plans to rewrite the binding (I guess his schedule is more likely to be tied to openSUSE 11.3 than our rather more urgent Lucid release). So unless someone else steps up within the next few weeks, this regression will stand for Lucid.

It's made more complex because it seems the g-k-s API bears little relationship with what GAPI produces from the C source, so either every app needs to be ported to a brand new API, or significant time needs to be spent doing the binding by hand rather than via tools like GAPI.

[James P Michels III (james-p-michels)]

Can you list the functions from Gnome-Keyring that you are dependent on?

I have written clean PInvoke wrappers for the functions Gnome-RDP uses. If it's reasonable, I could write wrappers for other functions as well.

I am attaching the source code for what I've done thus far.

[James P Michels III (james-p-michels)]

Project files with libgnone-keyring.so PInvoke wrappers.

[Chris Halse Rogers (raof)]

I'll take this. Hopefully upstream just needs a prod to fix this there. If not, we can fix it in Lucid.

[Mkestner (mkestner)]

Not really a g-d-s bug. CCing gonzalo so he knows it's out here.

[James P Michels III (james-p-michels)]

Any status updates on this? I am certainly not a Debian expert, but I do have code (See attachment) ready to roll for Gnome-RDP, if needed. I'd also be willing to help out with other PInvoke mappings if it would help.

As I am pretty novice to this process, any guidance would be appreciated.

[Chris Halse Rogers (raof)]

I'm hoping to collaborate with upstream to fix gnome-keyring-sharp properly. We'd really prefer not to patch apps just for lucid & then have to revert once g-k-s is fixed, and we really don't want to ship a gnome-keyring-sharp with a different API to upstream.

[James P Michels III (james-p-michels)]

Obviously, fixing gnome-keyring-sharp is the most reliable way to solve this problem, but do you have the resources to get it fixed in time?

For Gnome-RDP, I am not sure I see the benefit of taking a dependency on library that does little more than PInvoke 3 functions for me. Doubly so when that library seems to be somewhat abandoned and out of sync.

In any case, I am new to the process, so I am more inclined to sit back, listen, and learn for now.

Can someone give this Debian/Ubuntu noob info on when the final cutoff is to submit a Gnome-RDP fix for this if gnome-keyring-sharp is not fixed in time?

Thanks.

[Chris Halse Rogers (raof)]

https://wiki.ubuntu.com/LucidReleaseSchedule is the relevant release schedule page. Since GNOME-RDP is in Universe, fixes can go in relatively easily until FinalFreeze on the 15th of April, and potentially after that, too.

[James P Michels III (james-p-michels)]

Lucid does not seem to be creating a symbol link for libgnome-keyring.so. Am I wrong to expect there to be one at release?

[Chris Halse Rogers (raof)]

The libgnome-keyring.so symlink is shipped in the -dev package; users of
libgnome-keyring should be linking against the current SONAME, which is
libgnome-keyring.so.0.

[Chris Halse Rogers (raof)]

I want to have this bug fixed for Ubuntu 10.04, which means soon.

Since the socket interface has gone away, (I don't think) the DBus interface is not fully ready yet, and a GAPI binding would have a significantly different API, I'm going through and re-implementing g-k-s by p/invoking libgnome-keyring. This seems the least effort to get something working for Lucid without breaking API.

Once I'm done I'll post a patch or branch or both for merging upstream.

[Chris Halse Rogers (raof)]

This is almost done. I just need to find where it's triggering a gnome-keyring-daemon crasher bug & do the autofoo.

[Chris Halse Rogers (raof)]

There's a bzr branch up on at https://code.edge.launchpad.net/~raof/gnome-keyring-sharp/pinvoke-libgnome-keyring which has the g-k-s API re-implemented as a p/invoke wrapper around libgnome-kerying.

There's also a bit of a test-suite there, but it tends to kill gnome-keyring-daemon (not the fault of g-k-s - this is bug https://bugzilla.gnome.org/show_bug.cgi?id=614308).

I can push this as a single monolithic patch, or to an svn repository, or a git repository, or whatever is most convenient.

[Chris Halse Rogers (raof)]

Created an attachment (id=351380)
Reimplement g-k-s using libgnome-keyring

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-keyring-sharp - 1.0.0-2ubuntu1

---------------
gnome-keyring-sharp (1.0.0-2ubuntu1) lucid; urgency=low

  * Upload to Lucid from pkg-cli-libs svn
  * Move to source format 3.0 (quilt)
  * debian/patches/02_gnome_2.30_compatibility.patch:
    + Replace socket use with a wrapper around libgnome-keyring.
      Makes gnome-keyring-sharp able to work on GNOME 2.30. (LP: #536925)
  * debian/rules:
    + Move to using override_dh_*
    + Run autoreconf before configure, and clean up afterwards in clean
    + Remove the bz2 -> gzip conversion from get-orig-source; 3.0 handles
      bz2 orig tarballs for us.
    + Override dh_makeshlibs, as it gets confused by the private glue library.
  * debian/control:
    + Bump debhelper depends to 7.0.50~ for override_dh_*
    + Now arch: any, due to libgnome-keyring-sharp-glue.so
    + Add new build-depends: libgnome-keyring-dev, automake, libtool,
      glib-sharp.
    + Drop unneded ndesk-dbus build-depends.
    + Bump Standards-Version. No changes needed after move to 3.0 (quilt)
  * debian/libgnome-keyring1.0-cil.install:
    + Also install libgnome-keyring-sharp-glue.so and Gnome.Keyring.dll.config
  * debian/copyright:
    + Replace (c) → ©. Fixes lintian warning.
 -- Christopher James Halse Rogers <email address hidden> Tue, 30 Mar 2010 17:58:48 +1100

[Martin Pitt (pitti)]

Chris, is that actually an issue with f-spot? or was the g-keyring fix sufficient? This f-spot task currently blocks the lucid release, and I wonder whether that's justified?

[Chris Halse Rogers (raof)]

All the application bugs aren't bugs; this purely required fixes to the g-k-s library, no application changes.

[Christian Eide (christian-eide)]

Will this patch be pushed upstream any time soon?

[Bphilips (bphilips)]

This is affecting openSUSE 11.3, in particular f-spot and photo export:

[Warn 22:19:20.890] Caught an exception - The keyring daemon is not available (in `gnome-keyring-sharp')
  at Gnome.Keyring.Ring.SendRequest (System.IO.MemoryStream stream) [0x00000] in <filename unknown>:0
  at Gnome.Keyring.Ring.Find (ItemType type, System.Collections.Hashtable atts) [0x00000] in <filename unknown>:0
Marshaling activate signal
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Gnome.Keyring.KeyringException: The keyring daemon is not available
  at Gnome.Keyring.Ring.SendRequest (System.IO.MemoryStream stream) [0x00000] in <filename unknown>:0
  at Gnome.Keyring.Ring.GetDefaultKeyring () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager.WriteAccounts () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager.MarkChanged (Boolean write, FSpotSmugMugExport.SmugMugAccount changed_account) [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager.MarkChanged () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager.ReadAccounts () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager..ctor () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugAccountManager.GetInstance () [0x00000] in <filename unknown>:0
  at FSpotSmugMugExport.SmugMugExport.Run (IBrowsableCollection selection) [0x00000] in <filename unknown>:0
  at FSpot.Extensions.ExportMenuItemNode.OnActivated (System.Object o, System.EventArgs e) [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0
  at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0
  at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0
  at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <filename unknown>:0
  at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0
  at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0
  at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x000...

[Bphilips (bphilips)]

Fedora 13 seems to have a fix:
 https://bugzilla.redhat.com/show_bug.cgi?id=595457

[Christian Krause (chkr)]

(In reply to comment #7)
> Fedora 13 seems to have a fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=595457

Just to avoid any misunderstandings:

In the Fedora package I have just used Chris Roger's patch from Comment #4. ;-) Works without any problems so far (Thanks, Chris!).

[Gonzalo-novell (gonzalo-novell)]

I have applied Chris' patch to gnome-keyring-sharp trunk (r159750).
Thanks a lot Chris!

[Gonzalo-novell (gonzalo-novell)]

Btw, also updated the version to 1.0.2 (assembly version is still 1.0.0.0).

[Bphilips (bphilips)]

(In reply to comment #10)
> Btw, also updated the version to 1.0.2 (assembly version is still 1.0.0.0).

Can you push this to openSUSE:Factory and openSUSE:11.3? I don't see it in Mono:Factory yet either:
 https://build.opensuse.org/package/view_file?file=gnome-keyring-sharp.changes&package=gnome-keyring-sharp&project=Mono%3AFactory

Thanks :)