Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer kwallet over libsecret for KDE #111

Merged

Conversation

ckamm
Copy link
Contributor

@ckamm ckamm commented Jun 14, 2018

See discussion in #99 #103 and owncloud/client#6455

@ckamm
Copy link
Contributor Author

ckamm commented Jun 14, 2018

Suggestions:

  • @ogoffart or @guruz could already review
  • we'll ask on a kde mailing list about whether this looks right

Copy link
Contributor

@ogoffart ogoffart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Altought it would be better to have a fallback if kwallet5 is not running

@@ -91,13 +99,18 @@ static KeyringBackend detectKeyringBackend()
case DesktopEnv_Plasma5:
return Backend_Kwallet5;
break;
// fall through

// fall through
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(nitpick: fall through what? there is already one return AND a redundent break :-) )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I didn't add it.

@@ -91,13 +99,18 @@ static KeyringBackend detectKeyringBackend()
case DesktopEnv_Plasma5:
return Backend_Kwallet5;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we check somehow if kwallet5 is running. And if it is not, then we'd fallback to libsecret?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will check.

@ckamm
Copy link
Contributor Author

ckamm commented Jun 14, 2018

@ogoffart Updated. But with this addition the risk of the change also increased since my kwallet detection code might be wrong.

@ckamm ckamm force-pushed the prefer-kwallet-over-libsecret branch from 4dfde7a to 9bd44f0 Compare June 14, 2018 11:44
@frankosterfeld
Copy link
Owner

Looks good to me. I wonder if KWallet4 is still the best fallback for non-KDE, but that's somewhat unrelated to this patch.

@ckamm
Copy link
Contributor Author

ckamm commented Jun 14, 2018

@frankosterfeld So we merge this, adjust the changelog, bump the version to 0.9.0, bump the version for master?

return Backend_LibSecretKeyring;
}

if ( GnomeKeyring::isAvailable() ) {
return Backend_GnomeKeyring;
} else {
return Backend_Kwallet4;
Copy link
Contributor

@ogoffart ogoffart Jun 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change to Backend_Kwallet5

So this would cover the use case that we are running Plasma 5, but neither isKwallet5Available() nor LibSecretKeyring::isAvailable() (because the application just started at startup before kwallet5d is running)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that might happen during startup. So:

Plasma: Try kwallet5, try libsecret, try gnome-keyring, fallback kwallet5
Gnome and others: Try libsecret, try gnome-keyring, try kwallet5, fallback gnome-keyring

?

In particular, fallback onto gnome-keyring on gnome/unity and on
kwallet5 on plasma sessions.
@ckamm
Copy link
Contributor Author

ckamm commented Jun 25, 2018

@ogoffart Updated
@frankosterfeld How would you like to move forward with this?
@jnweiger Since we do want this for the upcoming releases you could build from https://github.com/ckamm/qtkeychain/tree/prefer-kwallet-over-libsecret if necessary, or have a patch for qtkeychain...

@frankosterfeld frankosterfeld merged commit 4fc8fc4 into frankosterfeld:master Jul 6, 2018
@guruz
Copy link
Contributor

guruz commented Jul 9, 2018

@frankosterfeld Hi! You would still need to :

thanks :)

@frankosterfeld
Copy link
Owner

@guruz yeah, i was waiting for #103, but I think I'll just do a release now, as it improves the situation

@guruz
Copy link
Contributor

guruz commented Jul 9, 2018

@frankosterfeld Sorry, didnt see that. Feel free to wait a bit more if needed.

@frankosterfeld
Copy link
Owner

Ok, I wait a few more days. Please ping me if I didn't release by the end of the week ;)

@guruz
Copy link
Contributor

guruz commented Jul 13, 2018

@frankosterfeld from our side, it would be OK to have the release. Waiting for #103 is not important.. :)

@frankosterfeld
Copy link
Owner

@guruz done!

@guruz
Copy link
Contributor

guruz commented Jul 13, 2018

@frankosterfeld Thanks a ton :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants