Secret schema on Linux is inconsistent with keytar

[ccope]

Describe the bug
Unfortunately it doesn't seem like there are predefined schemas for secrets in the freedesktop secretservice backend, other than for network servers. Keytar chose to use account and keyring chose username. Setting both fields would allow the libraries to interoperate. Alternatively, giving the user the ability to override the schema would allow them to fix this themselves, but then it's still likely that different library developers would choose incompatible schemas.

keytar is the most popular keychain library on NPM, so sharing a common schema would be likely to increase compatibility with Node applications that interface with common services.

https://github.com/atom/node-keytar/blob/master/src/keytar_posix.cc#L14-L17
https://github.com/jaraco/keyring/blob/master/keyring/backends/SecretService.py#L84-L87

To Reproduce
Steps to reproduce the behavior:

1. Add a secret with either library.
2. Try to retrieve the secret with the other library.
   [it fails]

Expected behavior
The secret should be returned

Environment

• Ubuntu 18.04

$ pip list | grep keyring
10.6.0
...
$ keyring --list-backends
<keyring.backends.SecretService.Keyring object at 0x7f3a3a747550>
<keyring.backends.fail.Keyring object at 0x7f3a3696e898>

[ccope]

Also filed ticket on keytar: atom/node-keytar#223

[jaraco]

Happy to align with established patterns. I'd recommend the pattern that is dominant (>70% users) or established first should take precedence. Under that recommendation, which system should change?

If keyring were to change, there would need to be a transition and probably a migration process. It'll be an involved transition. Is that something you'd be willing to own (or sponsor)?