On Sun, Mar 10, 2019 at 06:50:23PM +0100, Oliver Runge wrote: > I used PassCmd, but neither `gpg -d .authinfo.gpg` nor `security > find-generic-password [...]` are a good choice in my eyes, because I'd > have to type in my local password (GPG or Keychain access) each time > or add a rule to cache it in gpg-agent or always allow security access > to the Keychain. The latter options allow anyone who gains access to > my machine to retrieve my password on the command line. > > With the Keychain access directly from mbsync, however, Keychain can > do the access control based on the process's binary, shutting down > this particular attack possibility. > it's a pity the security command does not forward that information to the keychain - it would only need to look at its parent process or the other end of the pipe.
in principle it would be possible to do just that with a custom mbsync-keychain-client tool. > Let me know whether this you'd consider merging this or if it needs changes. > i'm not exactly thrilled, but i can see the argument, and the idea with the external tool seems slightly over-engineered. you entirely blew the formatting (tabs and internal spaces). at this time, it's "macOS", not "MacOS X", "OSX", or anything else. i didn't look too closely at the code yet, but it doesn't seem egregiously bogus. > PS: this sort of thing could also be done with the GNOME Keyring or KDE Wallet > yes, it would, theoretically (in practice, kwallet-query doesn't appear to to need confirmation). but linux distros would hate that - because unlike on macos, this would pull in additional dependencies which are specific to the particular desktop. this would be sort of an argument for externalizing it on macos as well - for consistency. i'm torn. ^^ _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
