Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ueno opened this issue Nov 14, 2023 · 6 comments · May be fixed by #73
Open

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

ueno opened this issue Nov 14, 2023 · 6 comments · May be fixed by #73
Assignees
Labels

Comments

@ueno
Copy link
Collaborator

ueno commented Nov 14, 2023

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
Copy link
Owner

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
Copy link
Collaborator

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
Copy link
Collaborator Author

ueno commented Nov 14, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator Author

ueno commented Nov 18, 2023

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

@warusadura
Copy link
Collaborator

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

gnomesysadmins pushed a commit to GNOME/libsecret that referenced this issue Nov 28, 2023
The original code tries to encrypt the file format using AES-256-CBC,
though actually AES-128-CBC was used because the key size is shorter
and libgcrypt automatically degrades to AES-128-CBC based on the key
size.  Reported by Sophie Herold in:
bilelmoussaoui/oo7#46 (comment)

Signed-off-by: Daiki Ueno <[email protected]>
@bilelmoussaoui bilelmoussaoui linked a pull request Feb 15, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants