Add some documentation

[DamienCassou]

I've just discovered pass_secret_service. I think the following could be added to the README:

1. some known users of the secret_service dbus API (is the API used at all?)
2. other implementations of the secret_service dbus API (in case pass_secret_service doesn't work for someone)
3. a way to test that everything is set up properly
4. should users deactivate other implementations (if Gnome Keyring implements the API, should we uninstall it?)
5. what files/folders does pass_secret_service use in my password store
6. can I edit the files in secret_service/ folder myself?

[michaelk83]

1. some known users of the secret_service dbus API (is the API used at all?)

Any app that uses libsecret, which is probably most GNOME apps (those that have any secrets to store), some KDE apps, and various scripts and tools. KDE apps are supposed to be migrating to QtKeyChain, which supports both KWallet and libsecret backends.

2. other implementations of the secret_service dbus API (in case pass_secret_service doesn't work for someone)

The main ones are Gnome Keyring, KWallet (as of the very recent 5.97.0), and KeePassXC. There is also mvdan/bitw for BitWarden.

4. should users deactivate other implementations (if Gnome Keyring implements the API, should we uninstall it?)

Yes. Of the main three, Gnome Keyring is the most problematic, since it doesn't play nice with other Secret Service providers (gnome-keyring#86). You may need to uninstall it, unless they added a "Disable" option. If you don't uninstall it, make sure that gnome-keyring-daemon process is not running (and isn't getting respawned).

With KeePassXC and KWallet, you can disable Secret Service integration from their settings. You may need to restart the kwalletd5 process (or shut it down if you don't need KWallet).

On KDE, QtKeyChain currently prefers the KWallet API if it's available (qtkeychain#220, qtkeychain#171), so you may need to disable KWallet entirely.

3. a way to test that everything is set up properly

• busctl --user | grep secret should list org.freedesktop.secrets as either activatable or running. If running, it should list the process as pass_secret_service.
• qdbus org.freedesktop.secrets should list all your collections and items (if there are any, and the service is running). This looks like a bunch of /org/freedesktop/secrets/collection/xxxx/iiii lines, where xxxx is the collection name, and iiii is the item index.
• Use secret-tool (CLI) or Seahorse (GUI) clients to inspect and modify secrets via the Secret Service API.

See also #32 (comment)

[DamienCassou]

Thank you very much for your detailed answers. My point was more about adding this information to the README so everyone can see it quickly.

[michaelk83]

My point was more about adding this information to the README

That's up to the developer. But better here than nowhere.

[mdellweg]

I must confess, i cannot divert a lot of time to this project as of by now. But i'd be happy to see this as a contribution.

[michaelk83]

I think this can be left here for now. Adding this to the readme would require some rearrangement into appropriate sections, and better formatting. The issue references wouldn't be appropriate there, either.

[Thaodan]

6. can I edit the files in secret_service/ folder myself?

I wonder the same like can I use existing keys that is already the in the same keyring/passwordstore.
Often I already have similar keys that used by services that come from the same LDAP/Identity-Management.