Support for libsecret's dbus API -- community tools discussion

Ask the Community Password Manager
, ,
1

Hello all.

I just stumbled across this thread so I thought I’d share.

I too got annoyed by this, and wrote a service called rosec/rosecd. You can find it here - GitHub - jmylchreest/rosec: A secrets daemon implementing the freedesktop.org Secret Service API with modular backend providers · GitHub .

I’ve yet to package it for anything except arch (i’ll push it to the AUR shortly) but in short:

It’s a secure rust based daemon/client. It sits on the secrets dbus endpoints and an additional rosec.Daemon IPC. It has a built in prompter and fundamentally does the following:

Supports n+1 different backends: local vault (RW), bitwarden password manager (RO), bitwarden secrets manager (RO), and soon a direct RO way to access gnome-keyring files directly too for migration.

It has an SSH Agent, and it also exposes the ssh keys via a secure fuse mount - these are across all unlocked backend providers. If you add an ssh-host (or several) attributes to your ssh keys it’ll also create the ssh configs you can just include within that fuse fs too, and ssh-user to set the username.

It supports prompt, search, get, create etc with writes being made to the RW vault options (currently only an encrypted local vault).

It’ll support PAM unlock and MFA vut I’ve not tested these much, and with the rosec client supports pretty rich search functionality.

Collections can be mapped, so writes/reads can be specifically routed but right now, and primarily because of the spec, it only works on the default collection.

Ther eis also a concept of opportunistic unlock, whereby a password will be attempted to unlock across all providers when entered, so if you do happen to share a password, it’ll unlock them all.

Theres a few other things, such as auto lock via logind or a timer, a max unlock period, etc.

most providers are written as WASM guests, they are truly isolated and fully destroyed, and they share no content persistently to disk.

I’m sure there is plenty it needs, but i’ve been using it for a week or so and I have been improving it throughout - maybe it’s useful to you as well.

1 Like
2

Hello,

I too got annoyed by this, and wrote a service called rosec/rosecd. You can find it [on GitHub (jmylchreest/rosec)].

Thank you for sharing your work. You made a great job! That’s really a shame we did not discuss about all of this before :laughing:

It has a built in prompter […] Supports n+1 different backends: local vault (RW), bitwarden password manager (RO), bitwarden secrets manager (RO), and soon a direct RO way to access gnome-keyring files directly too for migration. […] It supports prompt, search, get, create, etc. with writes being made to the RW vault options (currently only an encrypted local vault).

My implementation is not as flexible as yours, and only intends to work with one kind of backend, namely the bitwarden password manager. It already supports RW. Basically, it communicates with the Bitwarden’s CLI client through a private UNIX socket using the Vault Management API (cf. the bw serve command). It also has a built-in prompter and multiple vaults can be configured.

It has an SSH Agent, and it also exposes the ssh keys via a secure fuse mount - these are across all unlocked backend providers. If you add an ssh-host (or several) attributes to your ssh keys it’ll also create the ssh configs you can just include within that fuse fs too, and ssh-user to set the username.

Mine does not provide a SSH agent. I have never considered it, because the official desktop client already does it.

It’ll support PAM unlock and MFA.

Adding a PAM module for auto unlocking the default collection upon a successful login is something I could also consider in the future. I do not intend to support MFA for now.

Collections can be mapped, so writes/reads can be specifically routed but right now, and primarily because of the spec, it only works on the default collection.

If by mapped you mean aliased, I found that gnome-keyring-daemon and KWallet, for example, handle this mechanism differently. I chose more or less the GNOME’s way, but I still do not know whether that was really the cleanest one.

I’ve been using it for a week or so and I have been improving it throughout.

I use mine for a few weeks too. My experience revealed some minor issues, all of which are now fixed (to the best of my knowledge :sweat_smile:). I have pushed what I consider the beta release today. My next priority might be supporting the XDG Secret Portal API.

maybe it’s useful to you as well

For sure it will be useful :winking_face_with_tongue:

Best regards,

PS – I had to delete an older message to be allowed to send this one; does anyone know how to avoid this?

3

@Tulkas59, which message did you observe?

@Volunteer_Moderator, this might be worth splitting into another thread.

1 Like
4

Hello,
I always receive something like “new members cannot send more than 3 messages in the same thread” (do not remember the precise text).
Have a good day,
PS - Do not know why this one could be sent! Maybe because I used the reply button?
PPS - I don’t want to pollute the thread. If it works… somehow… again… you can ignore my question for now :wink: Thank you for your help!

5

@rokejulianlockhart @Tulkas59 @jmylchreest I now moved the last posts out of that feature request (Support for libsecret's dbus API) and into this separate thread.

PS: @Tulkas59 I think you just have to “enter” (view) another topic to reach Trust Level 1 which lifts some restrictions.

2 Likes