-
Notifications
You must be signed in to change notification settings - Fork 160
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
Added config file to allow backend selection (linux) #103
base: main
Are you sure you want to change the base?
Conversation
It would be great to get this PR merged: the ownCloud client now ships qtkeychain with the libsecret backend enabled and there will likely be people who'd prefer to continue using the kwallet backend instead (see #99). With the config file setting there'd be an option for that. Alternatively there could be an API for controling backend choice. I'd be up for helping to get this to work. |
@ckamm did you review+test this PR? @frankosterfeld BTW, i think we (ownCloud client guys @ogoffart @ckamm @guruz @dschmidt ) are interested in taking over more power+responsibility here if needed. |
I can merge this, although having the user to do this choice seems like the very last resort to me. I definitely could help, I have no time for this project right now, especially those issues where I would have to test on a handful of different test setups. Especially on Linux, I'm out of the loop regarding the status of the various desktops and distributions. |
@frankosterfeld Do you know if libsecret is going to superseede kwallet on KDE? If not, maybe the detection code should prefer kwallet backends for KDE sessions, instead of always prefering libsecret? |
@ckamm yeah, i'm wondering if going back to kwallet by default would make sense, if it is running. But that's the part where I'm out of loop, I don't know what the status of kwallet vs gnome-keyring vs. libsecret is these days, both in deployed systems and in current development. |
@frankosterfeld At least for gnome sessions it looks like libsecret is preferred now - libgnome-keyring will actually be removed from some distros soon. For kde I don't know either unfortunately. It looks like mid 2016 there was talk of going to ksecretservice or libsecret: https://mail.kde.org/pipermail/plasma-devel/2016-July/055668.html |
@frankosterfeld I meant it the other way: We can help reviewing+merging stuff if you want. |
@guruz that would probably best, moving this out of my personal space and give you guys the correct permissions. |
There was a similar discussion here: jaraco/keyring#273 that ended up with them prefering the kwallet backend over the secret service dbus api. |
It looks like the secret service dbus api on kubuntu 18.04 is provided by gnome-keyring-daemon. Switching to libsecret will thus talk to a different keyring backend than before. I'll make a PR for prefering kwallet on kde sessions. |
} | ||
|
||
} | ||
|
||
static KeyringBackend getKeyringBackend() | ||
static KeyringBackend getKeyringBackend(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this change
return Backend_Kwallet4; | ||
} | ||
if (!disabled.contains(backendGnomeKeyring, Qt::CaseInsensitive)) { | ||
if ( GnomeKeyring::isAvailable() ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, but please cleanup the indentation (4 spaces, no tabs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Had this review unsubmitted here..)
@frankosterfeld will have a look at it, need to rebase though. |
@akallabeth would make sense to me |
@akallabeth Why do you want to use
|
@guruz thought it would make most sense to have such a setting per installation and not per user. |
@akallabeth I'd think user is better (it also falls back to system). |
#if QT_VERSION >= 0x050000 | ||
const QString prefix = "qt5-"; | ||
#else | ||
const QString prefix = "qt4-"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this prefix.
The settings should apply to both version equally.
Also, there should not be so many apps using Qt4 at this point anywyay.
#else | ||
const QString prefix = "qt4-"; | ||
#endif | ||
const QSettings settings(QSettings::SystemScope, prefix + "keychain"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not be system scope.
This is something the user would configure.
@@ -76,37 +82,68 @@ static DesktopEnvironment detectDesktopEnvironment() { | |||
return DesktopEnv_Other; | |||
} | |||
|
|||
static KeyringBackend detectKeyringBackend() | |||
static KeyringBackend detectKeyringBackend(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another useless "void"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, old C
habits, always forget that the definition in C++
differs ^^
static const QString backendLibSecret = "libsecret"; | ||
static const QString backendKwallet4 = "kwallet4"; | ||
static const QString backendKwallet5 = "kwallet5"; | ||
static const QString backendGnomeKeyring = "gnome-keyring"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, non-trivial static global object is to be avoided in libraries.
Edit: I'd use plain const char []
, or not have them there at all and just use the plain text in the function.
@akallabeth Any news on when you can update this? :) Otherwise it can't go into 0.9 (which is fine) |
/etc/xdg/qt5-keychain.conf
or/etc/xdg/qt4-keychain.conf
depending on Qt version compiled.backend=[libsecret|kwallet4|kwallet5|gnome-keyring]
a specific backend can be forced and autodetection disabled.disable-backend=[libsecret|kwallet4|kwallet5|gnome-keyring],[[[libsecret|kwallet4|kwallet5|gnome-keyring]]?
some / all backends can be skipped during auto detection