0.9.2 Release

[LeFroid]

0.9.2 Tasks (subset of requirements before v1.0 is ready)

• Experiment with autofill support for Windows and MacOS
• Gnome-keyring support as an alternative to KWallet on Linux
• Test coverage of all data store classes & management APIs (examples: bookmark store/mgr, history store/mgr, favicon store/mgr)
• Replace calls to sBrowserApplication with service locator and/or dependency injection in viper-core library
• Refactor out any code in viper-core that calls something in viper-ui (want to have one-way dependency, viper-browser -> viper-ui -> viper-core)
• Add FaviconStore and BookmarkStore to the new database worker thread / task scheduler (Edit: Cannot do this with FaviconStore, as it uses the QIcon type, and during tests it was concluded that a QIcon must be constructed in a Qt thread only)
• Implement UI for favoriting a new page on the "New Tab" html page. The backend code is already there, but the JS/HTML bindings are not yet implemented. (see a391a38 )

[ghost]

@LeFroid Do you need help with this project? I was looking for an alternative browser and this looks the closest to what I was looking for. I just think it could use a bit of work to get it to where I would want it to be for use as a daily driver.

[LeFroid]

@braewoods Thank you, I would certainly appreciate the help! There are a great many things that could be added, improved, or made more user-friendly, and I would like to hear your thoughts on the project.

[ghost]

@LeFroid My first observation is that it may be best to replace KWallet and the planned gnome-keyring support with libsecret integration instead since this can be used with KDE and GNOME with a single implementation. Each has their own implementation of it and there's also some third party ones like keepassxc.

[ghost]

@LeFroid Upon further investigation it appears kwallet does not have a libsecret backend so KDE does not support it either. But it appears your current implementation only supports one backend per build. Could we work around this problem by making the provider use plugins instead so it can be loaded dynamically at runtime?

[ghost]

I'll see if I can make the existing static build able to support multiple compile time options. This would give more flexibility I believe.

[LeFroid]

@braewoods The current interface should be flexible enough to use a dynamic plugin system. Qt has some existing interfaces we can use. I'll do some additional research on this.

[LeFroid]

@braewoods I've created a working POC using dynamic plugins to load the credential provider. Needs some refinement, but the code should be ready to push in the next two days.

[ghost]

@LeFroid Ok. The next question is how to select the one to use. We could have an automatic selection and a manual override.

For Linux I would think we would want to use KWallet when running under KDE and a libsecret based system for everything else.

[LeFroid]

@braewoods Good question. If we can assume that some environment variable is set at runtime by KDE, the application can look for that to determine the implementation. I'm not sure what other applications do, however, to check for this sort of thing.

I've moved the KWallet implementation to a plugin in the last commit; if you want to work on a libsecret plugin based on the current design, then by all means go ahead.

[ghost]

@LeFroid We could use XDG_CURRENT_DESKTOP environment variable to guess the running Desktop environment. It should be viable for any X11 or Wayland environment, Linux or otherwise. Here's what it's set to under KDE: XDG_CURRENT_DESKTOP=KDE

[LeFroid]

Looks good to me @braewoods . I'll add the check momentarily.
The AutoFill class will look for a plugin with QObject name "CredentialStoreKWallet" if the KDE condition is met, otherwise it will look for "CredentialStoreSecret" (placeholder).

[ghost]

@LeFroid I started work on the secret port. But I cannot find the class definition for WebCredentials. Where can I find its documentation? I'm guessing it is located somewhere in the QT documentation but I don't know where to look.

Edit: Nevermind, found it.

[ghost]

@LeFroid I've been looking at this again and I realized something about the KWallet implementation. It stores credentials in a memory cache. I was wondering if you want the same for Secret. This may have performance benefits but it comes at the expense of secrecy as it may allow passwords to be leaked from memory if an exploit is found. We've seen several such as spectre and heartbleed over the years where memory could be read by malicious scripts or programs that it wasn't supposed to be able to. By querying the credential provider directly for each operation we can limit this risk but I don't know how much performance would suffer as a result.