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

Bug #536925 reported by deichschuh
216
This bug affects 43 people
Affects Status Importance Assigned to Milestone
gnome-keyring-sharp
Fix Released
Unknown
bareftp (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Invalid
Undecided
Unassigned
docky (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Invalid
Undecided
Unassigned
f-spot (Ubuntu)
Invalid
High
Chris Halse Rogers
Lucid
Invalid
High
Chris Halse Rogers
gnome-do (Ubuntu)
Invalid
Undecided
Unassigned
Lucid
Invalid
Undecided
Unassigned
gnome-keyring-sharp (Ubuntu)
Fix Released
High
Chris Halse Rogers
Lucid
Fix Released
High
Chris Halse Rogers
gnome-rdp (Ubuntu)
Invalid
Undecided
James P Michels III
Lucid
Invalid
Undecided
James P Michels III

Bug Description

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

Revision history for this message
deichschuh (deichschuh) wrote :
Changed in mono (Ubuntu):
status: New → Confirmed
Revision history for this message
Jo Shields (directhex) wrote :

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

affects: mono (Ubuntu) → gnome-keyring-sharp (Ubuntu)
Revision history for this message
Jo Shields (directhex) wrote :

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

Jo Shields (directhex)
summary: - docky gmail checker is unable to connect to gnome-keyring
+ gnome-keyring-sharp uses deprecated socket interface; apps cannot use
+ keyring
Revision history for this message
In , Jo Shields (directhex) wrote :

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

Revision history for this message
Chris Halse Rogers (raof) wrote :

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

Changed in gnome-keyring-sharp (Ubuntu):
importance: Undecided → Critical
Revision history for this message
James P Michels III (james-p-michels) wrote :

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

Is anyone working on a new wrapper?

Revision history for this message
Jo Shields (directhex) wrote :

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.

Revision history for this message
James P Michels III (james-p-michels) wrote :

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.

Revision history for this message
James P Michels III (james-p-michels) wrote :

Project files with libgnone-keyring.so PInvoke wrappers.

Changed in gnome-rdp (Ubuntu):
status: New → Confirmed
assignee: nobody → James P Michels III (james-p-michels)
Revision history for this message
Chris Halse Rogers (raof) wrote :

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

Changed in gnome-keyring-sharp (Ubuntu Lucid):
assignee: nobody → Chris Halse Rogers (raof)
importance: Critical → High
Changed in f-spot (Ubuntu Lucid):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
importance: Undecided → High
status: New → Triaged
Changed in gnome-keyring-sharp (Ubuntu Lucid):
status: Confirmed → Triaged
Revision history for this message
In , Mkestner (mkestner) wrote :

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

Revision history for this message
James P Michels III (james-p-michels) wrote :

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.

Revision history for this message
Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
James P Michels III (james-p-michels) wrote :

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.

Revision history for this message
Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
James P Michels III (james-p-michels) wrote :

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?

Changed in gnome-rdp (Ubuntu Lucid):
status: Confirmed → Fix Committed
Revision history for this message
Chris Halse Rogers (raof) wrote : Re: [Bug 536925] Re: gnome-keyring-sharp uses deprecated socket interface; apps cannot use keyring

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.

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
Chris Halse Rogers (raof) wrote :

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

Changed in gnome-keyring-sharp (Ubuntu Lucid):
status: Triaged → In Progress
Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-keyring-sharp (Ubuntu Lucid):
status: In Progress → Fix Released
Changed in gnome-keyring-sharp:
status: Unknown → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

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?

Changed in f-spot (Ubuntu Lucid):
assignee: Canonical Desktop Team (canonical-desktop-team) → Chris Halse Rogers (raof)
Revision history for this message
Chris Halse Rogers (raof) wrote :

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

Changed in bareftp (Ubuntu Lucid):
status: New → Invalid
Changed in docky (Ubuntu Lucid):
status: New → Invalid
Changed in f-spot (Ubuntu Lucid):
status: Triaged → Invalid
Changed in gnome-do (Ubuntu Lucid):
status: New → Invalid
Changed in gnome-rdp (Ubuntu Lucid):
status: Fix Committed → Invalid
Revision history for this message
In , Christian Eide (christian-eide) wrote :

Will this patch be pushed upstream any time soon?

Revision history for this message
In , Bphilips (bphilips) wrote :
Download full text (3.5 KiB)

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...

Read more...

Revision history for this message
In , Bphilips (bphilips) wrote :
Revision history for this message
In , Christian Krause (chkr) wrote :

(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!).

Revision history for this message
In , Gonzalo-novell (gonzalo-novell) wrote :

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

Revision history for this message
In , Gonzalo-novell (gonzalo-novell) wrote :

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

Revision history for this message
In , Bphilips (bphilips) wrote :

(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 :)

Changed in gnome-keyring-sharp:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.