#17 Obtain passwords from GNOME Keyring

[Jonathan Wakely]

Use GNOME's libsecret API to obtain a password from the system keyring
e.g. GNOME Keyring or KWallet.

https://gitlab.gnome.org/GNOME/libsecret
https://specifications.freedesktop.org/secret-service/latest/

The new UseLibsecret config setting was modelled on the similar macOS-specific UseKeychain feature. This allows similar functionality on linux desktops.

[Jonathan Wakely]

Related:
https://sourceforge.net/p/isync/mailman/isync-devel/thread/CAHaCNWJpjM86a2sWK6Q-NYNgEwLECeXONhUcLCSV7BRP%2B0v79Q%40mail.gmail.com/#msg36608784

I suppose I could/should have added something about this to src/mbsyncrc.sample but the man page seems like a better place to put it.

[Jonathan Wakely]

Oh, I just used the default milestone of 1.5.0 for this ticket, without realising there's also a 1.4.5 milestone. That would be better IMHO :-) If this gets merged upstream I'd like to package it for Fedora, so getting it in the next release would be nice. It's a new feature but it's a pure extension with no impact on any existing features, so would be nice to have ASAP.

[Jonathan Wakely]

Small bugfix, the error string on a failed lookup was missing a newline.

[Oswald Buddenhagen]

doesn't look too bad at first sight. but it might take a while until i take a closer look.

---

the target is of course 1.5.0, as 1.4.5 would be a bugfix release.

---

+           srvc->pass = nfstrdup( password );
+           secret_password_free( password );

this construct subverts libsecret's efforts to prevent paging out passwords. a more elegant approach would be storing the pointer directly and using the right free() function later. but then, the further processing of the password will use regular memory anyway, so without jumping through even more hoops, the exercise would be pointless.
i suppose adding a comment to this effect would be sufficient.

---

as mentioned in the discussion of the keychain feature, the relatively heavy gnome-ish dependency may be considered problematic by less gnome-centric distros.
to work around this, you could offer a build variant where libsecret is dlopen()'d, so the distro can use a suggests/recommends stanza instead of a depends.

---

KWallet is incorrectly capitalized in the manual.

[Jonathan Wakely]

a more elegant approach would be storing the pointer directly and using the right free() function later.

The memory returned from the libsecret API is in memory anyway, so I don't think doing that would make any difference. The approach in my patch seems consistent with the handling of keys from the macOS keychain, and all other approaches in ensure_password. I could add a comment to my new code, but it seems like a pre-existing problem with ensure_password and not introduced by my changes.

the relatively heavy gnome-ish dependency may be considered problematic by less gnome-centric distros

Meh. They don't need to configure with --with-libsecret if they don't like it :-) I don't use GNOME, but my KDE systems already have libsecret installed (it's used by at least msmtp which I use). And libsecret isn't that heavy, it depends on glibc and gobject, but not gtk and other major pieces of GNOME.

KWallet is incorrectly capitalized in the manual.

Ah yes, thanks. Fixed in this updated patch.

[Oswald Buddenhagen]

the point is that libsecret locks the memory, so it's not swapped out.
i suppose keychain may be doing the same; i didn't check.
anyway, the idea is to point out that we aren't quite following the library's standards.

distros have an incentive to enable as many features as possible. it's nice when that doesn't pull in the kitchen sink (run ldd on mbsync vs. libsecret to see what i mean).