Add keystore support for keyring crate v4

[brotskydotcom]

Hey @landhb, remember me? I'm the maintainer of the keyring crate. I'm about to bring out keyring v4, now in alpha, and as part of that release I would like to move the keyutils credential store out of the keyring crate and into this crate (which was a dependency for it). My motivations for this are:

• I'm trying to get back to a very slim and simple keyring model, which just has one built-in credential store for each platform. (Keyring v3 introduced a requirement that clients think about what store they want to use, and that just confused them. They were a lot happier when keyring made that choice for them, so I'm trying to get back to that.)
• Keyring extensibility makes it super easy for people to bring their own stores, so there's no real advantage to having lots of stores built into the keyring crate itself. They can just use the keyring crate and this crate if they want to use the keyutils credential store.

I'm submitting a PR that adds support for use as a keyring credential store. The PR conditionalizes that support under a new "keystore" feature, so existing direct clients of this crate aren't forced into a fatter build if you release a new version that includes this PR.

Can you do me a favor and take a look and let me know if you'd be willing to accept this? I'd love to have this enhancement out when I do the final release of keyring v4.

Thanks!

[brotskydotcom]

From the issues and PRs, it looks like maybe you are busy these days and not actively maintaining this repo? I would be happy to help maintain it, if you're interested. Thanks.

[landhb]

Hey! Been a while haha

I definitely understand wanting to slim down keyring and not maintain an infinite amount of backends.

I do think the Linux situation is a bit unique though. Since keyutils is really the only ubiquitous backend on the platform (since it's an interface provided by the Linux kernel itself). Gnome is not present by default on a ton of systems Debian, Arch etc. But definitely will be on most Ubuntu installs that aren't headless. Just one survey I found: Desktop Environment.

My main use case that started this crate was my own Debian desktop, which uses KDE instead of Gnome.

We can maintain it here if required though, I do think the keyring docs should still mention this in the section about secret-service not working (which will apply to more than headless environments).

[brotskydotcom]

I agree completely that we need to keep the keyutils credential store well maintained and compatible with keyring. Unfortunately, there has been so much user confusion about keytuils credentials not surviving reboot that I really can't justify making it the single default keystore on Linux boxes, especially since secret-service runs on all the *nixen and keyutils doesn't.

I'm a little intrigued about your statement about KDE vs gnome. AFAIK KDE also implements the Secret Service interfaces on the bus, so a Linux box running KDE should work just fine with the dbus-secret-service (aka secret-service in the new keyring release) keyring implementation. If that's not true for you please do file a bug on keyring-rs.

By the way, I've started a new organization on GitHub: the Open Source Cooperative. It's meant to be a home where projects that were originally owned by one person but are now maintained cooperatively can live, so that the original owners don't have to stay available forever. Walther has moved keyring-rs and secret-service-rs to that coop, I am moving dbus-secret-service there, and I will be inviting you to move keyring there as well.

Let me know if there's anything you need me to do to the PR in order to accept it for keyring, and if you want help with ongoing maintenance of this crate feel free to make me a maintainer - I'm retired now so actually have time for this fun stuff. :)

[brotskydotcom]

FYI, I am going to move dbus-secret-service keystore into its crate as well. I will probably still use dbus-secret-service as the default keystore on *nix in the keyring crate, but it will be trivial for people to use one or more of the others instead (or in addition).