On Monday 17 June 2013 13:48:39 Jan Kundrát wrote: > On Sunday, 16 June 2013 14:14:17 CEST, Pali Rohár wrote: > > Ok, so if I choose QtKeychain for implementing gsoc kwallet > > support, there could be problem with packaging. But benefit > > is support for Apple & Gnome. If I choose kwallet library > > directly, there will be no packaging problems, but it does > > not support Gnome secure storage yet. But in future there > > could be one. > > Right, it looks like QtKeychain does everything we require. > What about the following, then: > > - if there's no QtKeychain at build time, disable password > storage altogether and have Trojita ask for one when needed > (the PWs shall still be "remembered" in memory while the > session is active) - if QtKeychain is detected and enabled, > use it and don't support any other password storage (but > still store it in memory) > > When done properly, it should be possible to override the > automagic dependency resolution via a flag to qmake/cmake to > make packagers happy. >
I think this is against "plugin" idea when you can choose some password "provider" (by plugin) and you are forced to use what is supported by external library... So rather do not create some password plugin API and integrate QtKeychain support directly into Trojita (plus option to disable it at compile time)? My idea was that I will choose KWallet password storage from Trojita GUI and Trojita will use KWallet or show me error message (that KWallet is not installed/not running...) and I will have to choose other "provider" or plain text password storage. But using QtKeychain directly is not bad too. There could be problems like QtKeychain does not support other password storage used by system XYZ. But if Trojita have own password api it will not support it too. And adding support for that other password storage to QtKeychain can benefit also other applications using QtKeychain... So my question is: If Trojita will use QtKeychain library, do we need qt interface plugin API for password storage in Trojita? > > There could be another problem with QtKeychain library. > > Similar to contacts. If user change desktop QtKeychain can > > use another password storage (e.g kwallet is not running > > but secure storage yes). > > Understood. In my opinion, this is the cost which the distro > hoppers have to pay for now. > > If someone sees a problem with this approach, now it's the > time to speak up. > > With kind regards, > Jan Kevin, do you know if it is possible to tell QtKeychain to use *only* kwallet (or gnome secure storage)? Or at least warn user if want to use kwallet, but it is not available now? This could fix above problem (when you "rebooting" to other desktop and want to always use same password storage). -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
