SecretService KWallet backwards compatibility

[Steve-Tech]

Describe the bug
KWallet has support for SecretService now, however, KWallet created entries appear to store the service as 'server' in SecretService, while SecretService created entries do not show up at all in the KWallet interface.

For example, this is a KWallet created entry, in GNOME Passwords:

and, here's a Secret Service created entry:

To Reproduce
Steps to reproduce the behavior:

1. Create an entry using KWallet

   PYTHON_KEYRING_BACKEND=keyring.backends.kwallet.DBusKeyring keyring set example_service example_user

2. Requesting the entry using SecretService doesn't return anything

   PYTHON_KEYRING_BACKEND=keyring.backends.SecretService.Keyring keyring get example_service example_user

The opposite also doesn't work.

Expected behavior
I expected get_password to work for both backends when both backends are supplied by KWallet.

Environment

• OS: Debian Forky

$ pip list | grep keyring
bash: pip: command not found
$ apt list --installed python3-keyring python3-secretstorage
python3-keyring/testing,testing,unstable,unstable,now 25.6.0-3 all [installed,automatic]
python3-secretstorage/testing,testing,unstable,unstable,now 3.4.0-1 all [installed,automatic]
$ keyring --list-backends
keyring.backends.SecretService.Keyring (priority: 5)
keyring.backends.kwallet.DBusKeyring (priority: 5.1)
keyring.backends.kwallet.DBusKeyringKWallet4 (priority: 4.1)
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.libsecret.Keyring (priority: 4.8)
keyring.backends.chainer.ChainerBackend (priority: 10)

Additional context
The ChainerBackend does still work so this isn't an urgent issue, but I still thought it was worth raising to make it known. I believe a possible solution is to query both 'service' and 'server' for SecretService. KWallet will also only show entries with 'server', not 'service'.

[mitya57]

Ah, I see what happens here.

The Secret Service backend was written at a time when KWallet did not support Secret Service yet, so the question of compatibility did not stand.

And if we change the way how Secret Service backend works now, it will break compatibility with items created with that backend during the last few years.

One potential solution would be keep creating the new items the current way, but when retrieving items, make the Secret Service backend support (and return) items created by the KWallet backend. Will that suit you?

A PR is always welcome, but I can try to prepare one myself, too.

[michaelk83]

Note that the current KWallet Secret Service implementation is using the QtKeyChain item schema, which is user, server, type. Going forward, it would be best to have both backends save using this schema for maximum compatibility. When reading, you can fallback to the alternative schema if user, server, type is not found.

ETA: Or, given that the Secret Service API supports multiple free-form attributes, you can combine both schemas.

[mitya57]

Actually we have this class, which allows changing schemata:

keyring/keyring/backend.py

Lines 263 to 284 in 71dedcb

	class SchemeSelectable:
	"""
	Allow a backend to select different "schemes" for the
	username and service.
	>>> backend = SchemeSelectable()
	>>> backend._query('contoso', 'alice')
	{'username': 'alice', 'service': 'contoso'}
	>>> backend._query('contoso')
	{'service': 'contoso'}
	>>> backend.scheme = 'KeePassXC'
	>>> backend._query('contoso', 'alice')
	{'UserName': 'alice', 'Title': 'contoso'}
	>>> backend._query('contoso', 'alice', foo='bar')
	{'UserName': 'alice', 'Title': 'contoso', 'foo': 'bar'}
	"""
	scheme = 'default'
	schemes = dict(
	default=dict(username='username', service='service'),
	KeePassXC=dict(username='UserName', service='Title'),
	)

We should probably add the QtKeyChain schema there.