Created attachment 511764 [details]
net-libs/signond is used as a backend for packages such as kde-apps/kaccounts-integration and kde-apps/kaccounts-providers, but does not have USE flags nor dependencies to pull in at least one of the secure SecretsStorage backend plugins. If no backend plugins are found, signond falls back to a "default" unencrypted plain-text SQLite DB to store its secrets as described in the /etc/signond.conf bundled with the net-libs/signond package.
It's fairly trivial to check whether this insecure default backend is in use, for example a KDE user with kde-misc/kio-gdrive installed may configure an online account through systemsettings5 -> Online Accounts -> Create -> Google. After following the steps in the GUI, open signond's SQLite database through the terminal and perform a .dump to print the password that was submitted back in unencrypted plain-text: sqlite3 ~/.config/signond/signon-secrets.db
Luckily, KDE users can easily resolve this issue by manually pulling in the kde-apps/signon-kwallet-extension package as recommended per the documentation on: https://community.kde.org/KTp/Setting_up_KAccounts#Wallet_support
A gnome-keyring plugin exists as per /etc/signond.conf which refers to https://launchpad.net/signon-keyring-extension, but it doesn't appear to be in the Gentoo Linux tree at this time.
In my opinion, we should avoid storing secrets in the insecure default SQLite DB at all costs. Perhaps it would be a good idea to add a REQUIRED_USE "at least one of" style operator to the ebuild to make sure the end user has to install at least one secure SecretsStorage backend, starting with kwallet or gnome-keyring.
I have uploaded a suggested ebuild for net-libs/signond-8.59-r1 which adds the required kwallet USE flag and in turn has an RDEPEND for "kwallet? ( kde-apps/signon-kwallet-extension )". I couldn't add a gnome-keyring USE flag and RDEPEND entry at the same time because the signon-keyring-extension plugin is not in the tree yet.
Created attachment 511766 [details]
Thanks for your report, it is always better if you attach unified diffs over the most recent ebuild instead of the full ebuild, so your changes can be reviewed.
Created attachment 511880 [details, diff]
Thanks for the hint, I wasn't aware that a different format is preferred. I have attached the unified diffs you've asked for your review and obsoleted the old attachments.
Created attachment 511882 [details, diff]
Created attachment 512680 [details, diff]
The ebuild which I proposed last week results in circular dependencies on a system which doesn't already have both packages installed. Please excuse the newbie mistake on my part! ;-)
* Error: circular dependencies:
(net-libs/signond-8.59-r1:0/0::local, ebuild scheduled for merge) depends on
(kde-apps/signon-kwallet-extension-17.12.0:5/5::gentoo, ebuild scheduled for merge) (runtime)
(net-libs/signond-8.59-r1:0/0::local, ebuild scheduled for merge) (buildtime)
* Note that circular dependencies can often be avoided by temporarily
* disabling USE flags that trigger optional dependencies.
Perhaps the cleaner solution, in this case, would be to modify the ebuild for kde-apps/kaccounts-integration so that it has a kwallet USE flag with an RDEPEND on kde-apps/signon-kwallet-extension when enabled. This was the upstream's recommended setup, and for users with the desktop/plasma profile the kwallet USE flag is going to be enabled by default anyway.
That'll leave the Gnome team to decide what they'd like to do for the net-libs/signond integration with signon-keyring-extension. I'm not sure what'd be the best approach for other projects which may depend on net-libs/signond.
Created attachment 512682 [details, diff]
I'm not sure about the best course of action here. Portage does not really support optional runtime deps, and USE flags exclusively in RDEPEND are frowned upon. If we add it unconditionally, definitely some people will complain.
Until there is real support for it in Portage we typically solve situations like these via an elog/optfeature message in pkg_postinst.
Right now we have the following dependency chain: