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.
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.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.
Small bugfix, the error string on a failed lookup was missing a newline.
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.
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.
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 withensure_password
and not introduced by my changes.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.Ah yes, thanks. Fixed in this updated patch.
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).