[Suggested Solution] Redux for Stored Auth on OpenVPN 3 Linux Clients #38

nf-brentsaner commented 2025年01月26日 20:02:55 +01:00

I know, I know. Hear me out.

A more sensible longterm solution for secret (creds, keys) storage on Linux might be D-Bus.

There is an existing implementation/standard/specification: libsecret
It is essentially intended to be the backend equivalent of macOS's Keyring or Windows' DPAPI, and agnostic of GUI vs. headless, and/or which DE's/WMs/other environments users may be using.

GNOME, KDE, and a slew of other software already support it.

• It requires no direct user interaction (a user's session upon successful login automatically grants access to their secrets store)
  • But allows for additional per-secret encryption if desired by user
• It is almost guaranteed to be on any Linux GUI system
  • And some headless
• It's available cross-distro
• It requires no workarounds

Further, it appears that OpenVPN is already using D-Bus, so it should be a familiar protocol that integrates into existing codestyle, convention, and codebase practices for OpenVPN.

I know, I know. Hear me out. A more sensible longterm solution for secret (creds, keys) storage on Linux might be D-Bus. There is an existing implementation/standard/specification: [libsecret](https://wiki.gnome.org/Projects/Libsecret) It is essentially intended to be the backend equivalent of macOS's Keyring or Windows' DPAPI, and agnostic of GUI vs. headless, and/or which DE's/WMs/other environments users may be using. GNOME, KDE, and a slew of other software already support it. * It requires no direct user interaction (a user's session upon successful login automatically grants access to their secrets store) * But allows for additional per-secret encryption if desired by user * It is almost guaranteed to be on any Linux GUI system * And some headless * It's available cross-distro * It requires no workarounds Further, it appears that OpenVPN is [already using D-Bus](https://codeberg.org/OpenVPN/gdbuspp), so it should be a familiar protocol that integrates into existing codestyle, convention, and codebase practices for OpenVPN.

dazo commented 2025年01月26日 21:03:27 +01:00

This is indeed the approach we want, as libsecret provides a reasonable approach for a broad variety of "key wallet", even outside the GNOME/KDE sphere.

The problem is that none has had time to prioritize this task. Patches are most welcome and I will definitely review them if they appear.

Btw. the proper URL for the docs is here: https://gnome.pages.gitlab.gnome.org/libsecret/

This is indeed the approach we want, as libsecret provides a reasonable approach for a broad variety of "key wallet", even outside the GNOME/KDE sphere. The problem is that none has had time to prioritize this task. Patches are most welcome and I will definitely review them if they appear. Btw. the proper URL for the docs is here: https://gnome.pages.gitlab.gnome.org/libsecret/

nf-brentsaner commented 2025年01月27日 00:29:15 +01:00

Ah! Sorry, I wasn't aware you already knew of it!

(I think what you linked is the C API, I wasn't sure if you had wanted that. But you're still correct; the most recent D-Bus API docs for secretservice (D-Bus service for libsecret) can be found here. Meant to link to/refer to that!)

Unfortunately I'm primarily experienced in Python and Go, but I do have experience with using secretservice via D-Bus (I released this) so I probably wouldn't be of much help for patches.

Ah! Sorry, I wasn't aware you already knew of it! (I think what you linked is the C API, I wasn't sure if you had wanted that. But you're still correct; the most recent D-Bus API docs for _secretservice_ (D-Bus service for libsecret) can be found [here](https://specifications.freedesktop.org/secret-service-spec/latest/ref-dbus-api.html). Meant to link to/refer to that!) Unfortunately I'm primarily experienced in Python and Go, but I do have experience with using secretservice via D-Bus (I released [this](https://pkg.go.dev/r00t2.io/gosecret)) so I probably wouldn't be of much help for patches.