Hi, On Mon, Mar 30, 2020 at 2:07 AM Gert Doering <g...@greenie.muc.de> wrote: > > Hi, > > On Sun, Mar 29, 2020 at 07:58:15PM -0400, Selva Nair wrote: > > Yes, that's right. However, that logic wont be proper on OS-X, would it? > > Command line users who use --log can still see password > > prompt on /dev/tty. We'll be breaking that behaviour. > > > > I considered checking for env vars like IV_UI_VER set by the UI > > client, but that's not readily accessible from auth_user_pass_cr() > > call. Alternatives like checking whether /dev/tty can be opened and/or > > systemd is available didn't appeal to me. If at all, that would have > > to be a separate patch. > > Not sure if the case "there is an active management client, and > --management-query-passwords is set, but we *could* ask on /dev/tty" > is really worth considering.
I agree, but the problem is that we currently do that when auth-file has username but no password. Current behaviour: if auth-file is set always read from it else query management if management-query-passwords is set etc. else ask on /dev/tty or windows console with a quirk that if auth-file has username but no password, ask on /dev/tty or console, not the management ever.. (ignoring systemd which just replaces the query on console). I'm all for changing the latter behaviour to query the management if possible, /dev/tty otherwise. But that's a regression and some may complain. Jonathan K. Bullard <jkbull...@gmail.com> wrote: > > If the OS X command line user was using --management-query-passwords > (as Tunnelblick does), they wouldn't see the password prompt on > /dev/tty, would they? In case of auth-file missing password, they would see it on /dev/tty on linux, and I would guess on OSX as well, but I've not checked. Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
