Server side support for D-Bus Secret Service API

bilelmoussaoui / oo7

James Bond went on a new mission as a Secret Service provider

https://bilelmoussaoui.github.io/oo7/oo7/

MIT License

63 stars 12 forks source link

Server side support for D-Bus Secret Service API #46

Open ueno opened 9 months ago

ueno commented 9 months ago

Although the D-Bus Secret Service API has several limitations and there is already a migration support from it to file storage, it would be nice if there is a server side implementation of the D-Bus API to make transition from gnome-keyring easier.

I would suggest having the server implementation backed by the oo7::portal::Keyring, while also providing automatic migration from the legacy keyring format.

bilelmoussaoui commented 9 months ago

Few notes:

The server side should be on a separate binary that uses oo7
Ideally, the legacy format support should be done separately after an initial server side implementation is added. Any new formats would need some basic tests (if there are any to copy from upstream)
If time allows, we should build a mock server using the server side support and properly test the whole dbus API instead of depending on the host keyring for that

sophie-h commented 9 months ago

while also providing automatic migration from the legacy keyring format

Do you know what the differences between the keyring formats are? oo7 uses the same format as libsecret inside Flatpaks. I always assumed those formats were the same.

ueno commented 9 months ago

The legacy keyring format is internally used by gnome-keyring, marked as "version 0" in the header (while libsecret one is the version 1). They are particularly different in that the legacy one encrypts everything as a whole, while the new one encrypts individual items.

sophie-h commented 9 months ago

Good to know. Might make sense to somewhat document those things somewhere.

I'm not that versed in crypto but while re-implementing keyring v1 I noticed that libsecret claims to use AES256 but doesn't pass a key long enough to do so, which causes libgcrypt to silently downgrade the encryption to AES128.

Maybe it would make sense to deprecate v1 and replace it with a v2 with stronger encryption before using it in even more places?

ueno commented 9 months ago

Oh, I wasn't aware of that; I agree that we should bump it then.

warusadura commented 9 months ago

If not anyone working on this, can you please assign this for me? @bilelmoussaoui