gnucash and gnome keyring

[Fabio Coatti]

In data sabato 18 aprile 2015 16:22:36,  Fabio Coatti ha scritto:
> FabioIn data venerdì 27 marzo 2015 11:09:32,  Coatti ha scritto:
> > In data mercoledì 25 marzo 2015 11:11:50, John Ralls ha scritto:
> > > > I'm using gnucash with mysql backend and I'm facing a possibly related
> > > > issue. My environment is KDE, but with all gnome/gtk libs needed by
> > > > gnucash. Every time I start gnucash and access mysql backed data,
> > > > gnucash
> > > > asks for database user/password, then for keyring password. I expected
> > > > that next time gnucash will ask only for keyring password, but instead
> > > > it
> > > > repeats the previous steps: mysql user/pass, then keyring. It seems to
> > > > me
> > > > that gnucash tries to save user/password in keyring but at following
> > > > access it does not checks for keyring, or fails the check.
> > > > It is not a showstopper, but it can be a bit confusing and time
> > > > consuming
> > > > for users: if the keyring is not available (understandable, as I'm
> > > > running on KDE), maybe gnucash should avoid to try to save the pass in
> > > > it
> > > > (or use kwallet instead, that would be a big win :D )
> > > 
> > > GnuCash itself doesn't ask for the keyring password, of course, Gnome
> > > Keyring does. But AFAICT from the code GnuCash should be querying the
> > > keyring for the password first and only asking for the password if it
> > > doesn't find it, so keyring should be asking for its password before
> > > GnuCash asks for the database password. I won't be able to debug this
> > > until
> > > I get back, so unless Geert can, it won't make 2.6.6.
> > > 
> > > Please file a bug so that this doesn't disappear into the fog of the
> > > mailing list archives.
> > 
> > Done, many thanks
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=746873
> 
> I looked a bit more into this issue and I found that if I change, in
> gnc-keyring.c, the schema flag to SECRET_SCHEMA_DONT_MATCH_NAME from
> SECRET_SCHEMA_NONE, all works just fine, that means gnucash make the
> request to keyring using libsecret, the keyring pops up the request for the
> unlock password and gnucash completes the login to mysql.
> 
> the change is the following:
> @@ -48,7 +48,7 @@ const SecretSchema* gnucash_get_secret_schema(void)
> G_GNUC_CONST;
>  const SecretSchema* gnucash_get_secret_schema(void)
>  {
>    static const SecretSchema secret_schema = {
> -    "org.gnucash.password", SECRET_SCHEMA_NONE,
> +    "org.gnucash.password", SECRET_SCHEMA_DONT_MATCH_NAME,
>      {
>        { "protocol", SECRET_SCHEMA_ATTRIBUTE_STRING },
>        { "server", SECRET_SCHEMA_ATTRIBUTE_STRING },
> 
> 
> I didn't searched a lot about this behaviour, but it seems that with "NONE"
> libsecret is not able to perform correct lookup, at least in my situation.
> I tried to create and lookup passwords with python and the behaviour is the
> same, even starting with a blank keyring, using
> Secret.password_lookup_sync() and Secret.password_store_sync()
> 
> I'm not sure why this happens, now it works but maybe someone can understand
> why. I think that there should be a more correct approach, this one seems
> just a workaround to me and with its own drawbacks.
> 
> btw, gnucash 2.6.6 (main from github), libsecret-0.18


Some more info: it could be problem related to how gnucash deals with libsecret. It tries 
to lookup a password before unlocking the keyring, but the documentation does not says 
that password lookup can prompt the user. schema name is not available when keyring is 
locked and the query fails. Ignoring schema name, the query works. I tried to add the calls 
to force libsecret to unlock keyring before looking for password and it seems to work as 
expected, even searching for a specific schema.

I'm trying to modify a bit the password lookup code in order to confirm this behaviour; the 
bug report is updated accordingly.



-- 
Fabio