Try to get QKeyChain as a framework
Open, Needs TriagePublic

Description

This would then be the client API, kwallet would become an implementation framework we need at Plasma runtime, not compile time.

Ideally we would add this within 5.X and we can start porting clients?

Maybe too radical, but since KWallet will no longer be a direct dependency of clients, can KeePassXC instead be used as the platform implementation?

ervin added a subscriber: ervin.Nov 24 2019, 11:40 AM

Maybe too radical, but since KWallet will no longer be a direct dependency of clients, can KeePassXC instead be used as the platform implementation?

I've been thinking about that as well (I would love to use such a mode). But that's more a "nice for later" thing, it's not blocking a KF6 existence (can be done during KF5 lifetime even) so can be done whenever if QtKeyChain joins KF.

can KeePassXC instead be used as the platform implementation?

If QKeyChain gains a backend then sure, everything will "just work".

I'm not sure we can depend on it (especially given this project seems to have a trillion forks) for our default implementation.

Talked to Frank, he's not opposed to this, but would like to know how much would need to change in the API for this first.
I guess the next step is doing a closer review of it then.

nicolasfella moved this task from Backlog to In Progress on the KF6 board.Dec 1 2019, 8:59 PM
vkrause moved this task from In Progress to Needs Input on the KF6 board.Dec 10 2019, 5:22 PM
ervin added a comment.Dec 12 2019, 8:11 AM

AFAICT it looks mostly fine to me API wise. It has its own job class, but I'm not sure it'd be worth porting to KJob to be honest so it could likely stay like this. Other than that changes would be mostly about coding styles and aligning the organization of the files and build system with other frameworks.

AFAICT it looks mostly fine to me API wise. It has its own job class, but I'm not sure it'd be worth porting to KJob to be honest so it could likely stay like this. Other than that changes would be mostly about coding styles and aligning the organization of the files and build system with other frameworks.

Changing to KJob would be a problem for Frank's use-cases I think, and it would make this a tier2 framework, so I'd agree it makes sense to keep that as-is. What about the name, can we keep that as well?

ervin added a comment.Dec 12 2019, 9:05 AM

You mean keeping it named QKeyChain?

I don't think this is a problem. Might look a bit odd on the new library naming because of the libKF5 prefix but I don't see that as a blocker.

dfaure added a subscriber: dfaure.Dec 12 2019, 9:39 AM

Q* always sounds like something is provided by Qt.

OTOH if the renaming is blocker for getting it as a framework, we can keep the name ;)

"KeyChain" already has the "K" prefix ;) so Let's just drop the Q

Hi!

I'm not opposed to make QtKeychain a KDE framework. I'm lacking time these days to properly maintain it, especially when it comes to testing changes and decisions that require an overview of what is used where on which Linux distribution. One thing to consider is always the compatibility at runtime on older distros, with obscure desktop environments, etc. I just lack the overview of what is used in which Ubuntu, Fedora, CentOS or whatnot and what is still worth supporting. (Gnome keyring vs. libsecret, etc.). So any help here is welcome :)

As for the API and implementation: I chose an async API mainly to avoid issues when hiding async (DBus) implementation behind a synchronous API. So I would keep it that way, although the implementation of other platforms is usually synchronous.

I would like to keep the lib free of any other KDE dependencies (like KJob), as one major use case is to add it as a "code snippet" to any Qt project, often using QMake. That's much easier if there's no additional dependencies.

As for the name, please note that its "Keychain", not "KeyChain" :)

Regarding naming, one thing to consider is compatibility with existing code. For that it might be worth keeping the names (and possibly even ABI) as-is for the KF5 series and adjust for KF6 only, when user code needs to be ported anyway. This does affect other about to be incubated frameworks too, see eg. Grantlee.