Store password in gnome-keyring NOT plain text

I had a look at the GnomeKeyring binding for vala,and this is the result of my first attempt.
Would be nice if someone could give me a little feedback.. =)

Yes, this is critical for me because most websites have password recovery via email (including Launchpad), and if my account gets hacked the consequences might be...
That's why I don't use Pidgin and mail notifiers anymore.

@Sergey "Shnatsel" Davidoff and off-topic: there is a pidgin-gnome-keyring [1] plug-in.

[1] http://code.google.com/p/pidgin-gnome-keyring/

There is a secret-storage-spec [1] freedesktop.org spec that is in the process of being drafted in cooperation by the GNOME Keyring and the KDE Wallet developers. It might be relevant to our case.

[1] http://freedesktop.org/wiki/Specifications/secret-storage-spec

Sergey, this report is about storing the password. Messages on disk are not and won't be encrypted.

Landroni, this is a nice find. Sergey, could you have a look at using the DBus API? If we could use the fdo API I think that would be great.

My installed gnome-keyring 2.32.1-1 provides it:

$ dbus-sane.pl org.freedesktop.secrets
I org.freedesktop.DBus.Introspectable
 M Introspect (out s data)
I org.freedesktop.DBus.Properties
 M Get (in s interface, in s propname, out v value)
 M Set (in s interface, in s propname, in v value)
 M GetAll (in s interface, out a{sv} props)
I org.freedesktop.Secrets.Service
 M OpenSession (in s algorithm, in v input, out v output, out o result)
 M CreateCollection (in a{sv} props, out o collection, out o prompt)
 M SearchItems (in a{ss} attributes, out ao unlocked, out ao locked)
 M Unlock (in ao objects, out ao unlocked, out o prompt)
 M Lock (in ao objects, out ao locked, out o Prompt)
 M GetSecrets (in ao items, in o session, out a{o(oayay)} secrets)
 M ReadAlias (in s name, out o collection)
 M SetAlias (in s name, in o collection)
 S CollectionCreated (o collection)
 S CollectionDeleted (o collection)
 S CollectionChanged (o collection)
 P Collections (ao, read)

So I was about to say let's go with the above patch, no need to block on DBus API.... then I noticed an inherent problem: the password will still be saved to disk in form of the mbsync configuration. Worse, if we wanted to avoid that by passing the password via command line it would leak into /proc. So I may have to suggest we wait with this for now.

Why not implement a hashing algorithm? Then upon each start-up of the app user must enter the password to decrypt the stored passwords? Just generate a random key at first-launch, and then the user inputs their password which will act as a salt. Should be simple enough for now, till we get keyring. :)

Gordo, because temporary solutions tend to stick, and using a keyring is not THAT difficult.

Using Gnome-Keyring would mean everybody will have to install this dependancy, and as a non-gnome user I think it would be best to find some independant method for password storage. Don't you think ?

Reinventing the wheel is always bad for a handful of reasons. There are only two open-source keyrings: gnome-keyring and KDE Wallet, and you'll have to choose one of them, or use a unified protocol (better), or add encryption as an optional component / recommended package (best). Other encryption solutions are proven to work poorly. For example, Eric Raymond's fetchmail didn't encrypt stored passwords at all, and that was intentional. You can read why he didn't add encryption support at http://catb.org/~esr/writings/homesteading/cathedral-bazaar/ar01s09.html

A hashing algorithm specific to Postler would mean we also must support custom UI for it and take care of all the details. Doesn't feel attractive.

Like I said above, if we can use org.freedesktop.secrets in the future that would probably be best to keep it flexible. Mind currently there is no re-usable solution outside kwallet and gnome-keyring. If you know of one, it's probably a good idea to tell them about the DBus interface.

Couldn't you provide the use of gnome-keyring first and then switch to the secret-storage-api as soon as it's finished?

Yes. Right now the blocker is a limitation in the current backend, if in doubt I'm not opposed to using GNOME keyring.