Re: [Openvpn-users] Management interface "echo" command standardization
On Monday, 27 November 2017 10:40:40 PM AEDT Jonathan K. Bullard wrote:
> Hi,
>
> On Mon, Nov 27, 2017 at 2:23 AM, Steven Haigh wrote:
> > On 2017-11-27 05:06, Selva Nair wrote:
> >> On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard
> >>
> >> wrote:
> >>> This:
> >>>
> >>> echo "msg This message"
> >>> echo "msg will be shown"
> >>> echo "msg"
> >>> echo "msg on four lines (the third line is empty)."
> >>> echo "msg-window the title"
> >>
> >> That nicely solves the problem of when to display the message.
> >
> > This seems to me to be a horrible solution that has been fixed in other
> > solutions for decades.
> >
> > We're doing string processing at this point - so why can't we use standard
> >
> > string formatters:
> > \n = new line
> > \r = new line
> > \t = tab
> >
> > These have been standard for as long as I can remember - and I'm getting
> > on.
> I think you're misunderstanding what program is doing what string
> processing (as I did until Selma clarified it for me).
>
> The escapes you describe ("\n", "\r", etc.) are processed by OpenVPN
> itself, not by GUIs such as Tunnelblick, and thus would already have
> been processed in the text of messages that the GUI receives from
> OpenVPN over the management interface. The only way to pass them
> through intact for the GUI to interpret them would be to
> double-backslash them (e.g. \\n), which might in some circumstances
> require yet another level (n).
>
> You can use multiple-backslash escaping for most characters if you
> want to include them in a message. However, commas cannot be included
> in strings "pushed" by the server, so we need a way to escape them
> that is _not_ processed by OpenVPN, so the escape sequence itself is
> passed intact to the GUI. Selma's proposal to use URL encoding (such
> as %2C for a comma) does just that.
Does it use \r\n or \n or \r as the end of line terminator? It may have been a
mistake to do this - and the lines probably should have been null-terminated -
but we're probably beyond fixing that at this stage.
If none of that can be done, then uri encoding scheme is probably the next
most common / well understood part of encoding for multiline / parser specific
text.
> > This would allow you to combine everything into a single command.
> >
> > I feel it is a creep in the wrong direction to get the openvpn client to
> > piece together your message. If you want to display something, it should
> > be
> > pieced together in your script, then sent to openvpn in a single, well
> > specified format.
>
> That won't work for "long" messages. (It's what I proposed until I
> understood the problems that need to be addressed.)
>
> And by "long" I mean "pretty short" : )
>
> OpenVPN options (including echo and push) are limited to about 255
> bytes. Those bytes would have to include the message itself, the
> message title, "push", "echo", whatever name we give the message
> command, and all separators, quoting and escaping. And some characters
> (all in some languages) require multiple bytes. So 255 is a very, very
> severe limitation.
I believe this should be addressed in OpenVPN anyway. There are many more
problems that could be solved with an increase in the max line size. My OTP
implementation would benefit as I've had to limit the token length to work
around this problem as well.
> So we need a convention for expressing and then combining relatively
> short pieces of a message. The "msg" and "msg-n" proposal does that:
> it allows long lines to be created (using "msg-n"), and allows
> multi-line messages without escapes ("msg", with it's implied
> newline).
--
Steven Haigh
📧 net...@crc.id.au 💻 http://www.crc.id.au
📞 +61 (3) 9001 6090📱 0412 935 897
signature.asc
Description: This is a digitally signed message part.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi,
On Mon, Nov 27, 2017 at 2:23 AM, Steven Haigh wrote:
> On 2017-11-27 05:06, Selva Nair wrote:
>>
>> On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard
>> wrote:
>>>
>>>
>>> This:
>>>
>>> echo "msg This message"
>>> echo "msg will be shown"
>>> echo "msg"
>>> echo "msg on four lines (the third line is empty)."
>>> echo "msg-window the title"
>>
>>
>> That nicely solves the problem of when to display the message.
>
>
> This seems to me to be a horrible solution that has been fixed in other
> solutions for decades.
>
> We're doing string processing at this point - so why can't we use standard
> string formatters:
> \n = new line
> \r = new line
> \t = tab
>
> These have been standard for as long as I can remember - and I'm getting on.
I think you're misunderstanding what program is doing what string
processing (as I did until Selma clarified it for me).
The escapes you describe ("\n", "\r", etc.) are processed by OpenVPN
itself, not by GUIs such as Tunnelblick, and thus would already have
been processed in the text of messages that the GUI receives from
OpenVPN over the management interface. The only way to pass them
through intact for the GUI to interpret them would be to
double-backslash them (e.g. \\n), which might in some circumstances
require yet another level (n).
You can use multiple-backslash escaping for most characters if you
want to include them in a message. However, commas cannot be included
in strings "pushed" by the server, so we need a way to escape them
that is _not_ processed by OpenVPN, so the escape sequence itself is
passed intact to the GUI. Selma's proposal to use URL encoding (such
as %2C for a comma) does just that.
> This would allow you to combine everything into a single command.
>
> I feel it is a creep in the wrong direction to get the openvpn client to
> piece together your message. If you want to display something, it should be
> pieced together in your script, then sent to openvpn in a single, well
> specified format.
That won't work for "long" messages. (It's what I proposed until I
understood the problems that need to be addressed.)
And by "long" I mean "pretty short" : )
OpenVPN options (including echo and push) are limited to about 255
bytes. Those bytes would have to include the message itself, the
message title, "push", "echo", whatever name we give the message
command, and all separators, quoting and escaping. And some characters
(all in some languages) require multiple bytes. So 255 is a very, very
severe limitation.
So we need a convention for expressing and then combining relatively
short pieces of a message. The "msg" and "msg-n" proposal does that:
it allows long lines to be created (using "msg-n"), and allows
multi-line messages without escapes ("msg", with it's implied
newline).
Best regards,
Jon
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
On 2017-11-27 05:06, Selva Nair wrote: On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard wrote: This: echo "msg This message" echo "msg will be shown" echo "msg" echo "msg on four lines (the third line is empty)." echo "msg-window the title" That nicely solves the problem of when to display the message. This seems to me to be a horrible solution that has been fixed in other solutions for decades. We're doing string processing at this point - so why can't we use standard string formatters: \n = new line \r = new line \t = tab These have been standard for as long as I can remember - and I'm getting on. This would allow you to combine everything into a single command. I feel it is a creep in the wrong direction to get the openvpn client to piece together your message. If you want to display something, it should be pieced together in your script, then sent to openvpn in a single, well specified format. It feels like getting openvpn to piece together what you really want is a workaround to make any plugin script easier - and putting the complexity into openvpn to compensate. -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
> > > some form of encoding, say url encoding like %27 for comma etc.? > Well, read that as %2C Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Sun, Nov 26, 2017 at 10:49 AM, Jonathan K. Bullard wrote: > Hi. (Top posting without quoting because I'm not reacting to specific > comments.) > > I think Selva's approach of separate commands instead of separate > fields in a single command is better for several reasons and withdraw > my earlier proposal. > Me too :) > > How about (1) the ability to append messages to each other, (2) a > "msg" command which concatenates a newline to the text of a message, > and (3) a "msg-n " command, which doesn't, and putting the title in > the command that causes display? > This is a very good idea. > > I think that would mean there is no need to escape anything or make > any OpenVPN changes, and it's easy to generate, read, parse, and > process. > > This: > > echo "msg This message" > echo "msg will be shown" > echo "msg" > echo "msg on four lines (the third line is empty)." > echo "msg-window the title" > That nicely solves the problem of when to display the message. One concern about quoting, though: As the most common use of this will be to push from the server, those quotes will need to be escaped. So I suggest an improvement: (i) If/when number of spaces between words is not significant, quotes are not necessary as the option parser concatenates all words after echo into one string with a single space between words. (ii) When space is significant as in your msg-n proposal below, quote the message excluding the keyword "msg" or "msg-n" Then the echo command could be specified as echo msg This message and its pushed version becomes push "echo msg This message" When quoting is required to embed spaces or otherwise echo msg "This messageisstretched " and push "echo msg \"This message isstretched \" " or using single quotes push "echo msg 'This messageis stretched ' " etc. Quoting the message by itself makes it easier on the eye, I guess. Users may still come up with creative ways of quoting as what eventually gets displayed will be what comes through the management interface after quote processing by the parser at the server side for the push, and the client side for the echo. We need only to carefully specify how the GUI will interpret the received echo message. > would display the following in a non-modal popup window with title > "the title". There is no need for an "OK" button if the window has a > close button, but that could be implementation-defined behavior. > > = > This message > will be shown > > on four lines (the third line is empty). > = > > > And > > echo "msg-n this other message" > echo "msg-n " > That could be echo msg-n '' and push "echo msg-n '' " (or use escaped double quotes). Arguably easier to read and write. echo "msg-n will all be" > echo "msg-n" > Such lines will have no effect, right? > echo "msg-n displ" > echo "msg-n ayed on one line." > echo "msg-window the title" > > which would display: > > == > this other message will all be displayed on one line. > == > Sounds good, otherwise. > (All spaces after the first one that follows "msg" or "msg-n" are > considered part of the text, so there are lots of spaces between > "message" and "will", "be" and "displayed" are separated by the second > space after "msg-n" in "echo "msg-n displayed on one line", and > "displ" and "ayed" are joined together because there is no such space > in "msg-n ayed on one line".) > > > What to do about wrapping lines that are too long (whatever that means > : ) after concatenation would be implementation-defined. > > > To display as a notification instead of a window, the last command > would be replaced by: > > echo "msg-notify the title" > > > To display a URL in a non-modal popup window with contents of URL > "the_url" and title "this is the title", the sequence could be: > > echo "msg the_url" > echo "msg-url this is the title" > > (One use of that would be to show a user _how_ to do something, like > changing a setting in the GUI, instead of just telling them to do it.) > > > Regarding length limits, I don't think we need to impose any limits > beyond the limits imposed by OpenVPN. The OpenVPN limitation on the > length of individual parameters and the limitation(s) of the buffers > in the management interface are the two limits I know of. A note about > those would be appropriate wherever these echo commands are documented > (in the management interface doc, I assume). > > Keeping track of "pending" information (such as the text to be > displayed to the user) must be considered: > > A. If a GUI disconnects from the management interface while the > VPN is still connected and then later reconnects to the management > interface. (Tunnelblick can do that -- we even let th
Re: [Openvpn-users] Management interface "echo" command standardization
Hi. (Top posting without quoting because I'm not reacting to specific comments.) I think Selva's approach of separate commands instead of separate fields in a single command is better for several reasons and withdraw my earlier proposal. How about (1) the ability to append messages to each other, (2) a "msg" command which concatenates a newline to the text of a message, and (3) a "msg-n " command, which doesn't, and putting the title in the command that causes display? I think that would mean there is no need to escape anything or make any OpenVPN changes, and it's easy to generate, read, parse, and process. This: echo "msg This message" echo "msg will be shown" echo "msg" echo "msg on four lines (the third line is empty)." echo "msg-window the title" would display the following in a non-modal popup window with title "the title". There is no need for an "OK" button if the window has a close button, but that could be implementation-defined behavior. = This message will be shown on four lines (the third line is empty). = And echo "msg-n this other message" echo "msg-n " echo "msg-n will all be" echo "msg-n" echo "msg-n displ" echo "msg-n ayed on one line." echo "msg-window the title" which would display: == this other message will all be displayed on one line. == (All spaces after the first one that follows "msg" or "msg-n" are considered part of the text, so there are lots of spaces between "message" and "will", "be" and "displayed" are separated by the second space after "msg-n" in "echo "msg-n displayed on one line", and "displ" and "ayed" are joined together because there is no such space in "msg-n ayed on one line".) What to do about wrapping lines that are too long (whatever that means : ) after concatenation would be implementation-defined. To display as a notification instead of a window, the last command would be replaced by: echo "msg-notify the title" To display a URL in a non-modal popup window with contents of URL "the_url" and title "this is the title", the sequence could be: echo "msg the_url" echo "msg-url this is the title" (One use of that would be to show a user _how_ to do something, like changing a setting in the GUI, instead of just telling them to do it.) Regarding length limits, I don't think we need to impose any limits beyond the limits imposed by OpenVPN. The OpenVPN limitation on the length of individual parameters and the limitation(s) of the buffers in the management interface are the two limits I know of. A note about those would be appropriate wherever these echo commands are documented (in the management interface doc, I assume). Keeping track of "pending" information (such as the text to be displayed to the user) must be considered: A. If a GUI disconnects from the management interface while the VPN is still connected and then later reconnects to the management interface. (Tunnelblick can do that -- we even let the user quit Tunnelblick or log out.) I'll probably have Tunnelblick save and restore any pending data in that situation. B. If the VPN disconnects or OpenVPN crashes while there is pending information, I think I'd just discard it on the assumption that it is incomplete and probably no longer relevant. Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Sat, Nov 25, 2017 at 5:04 PM, Jonathan K. Bullard wrote: > Hi, > > On Sat, Nov 25, 2017 at 2:21 PM, Gert Doering wrote: > > I missed something in your list, which *I* would like to see for > > my users - a way to send a message to the GUI to display in a popup > > window, intended for the users to see. > > > > Examples could be stuff like > > > > "you are using a server that will be going away soon, please get > >an updated profile from your system administrator" > > > > (like, when having to migrate due to CA rollover) > > > > or > > > > "your OpenVPN is old and has known security issues, please migrate > >to version 2.4.4" > > > > or even > > > > "please change your Tunnelblick settings to enable OpenVPN 2.4, > >for better performance and less battery usage (AEAD)" > > > > > > (typically controlled by a --client-connect script on the server side > > which looks at incoming IV_ attributes and decides what to send, whether > > to send it on every connect or just once a week, etc. - but that's > > somewhat out of scope, just to give a bit more background on what I think > > how I'd use it) > > > > > > Originally, I thought > > > > push echo 'my message' > > > > would do exactly this, but I've since learned that this is more > complicated, > > so we'll need to define a message type > > > > push echo 'message this is my message' > > > > or something, agree on max length, encoding, dialog behaviour (shall it > > be a tray message or non-modal dialog thing? do we want to have options > to > > select either?)... > > > > > > Since I'm just a demanding user, I leave the specifics of that to you :-) > > (I'm sure Arne will have some ideas as well) > > How about: > > - "echo message-window,title,subtitle,text": Display a non-modal > popup window with title "title", subtitle "subtitle", text "text" and > a localized "OK" button. > This looks good, though sending title and subtitle in separate echo commands would make it simpler: no comma delimited text needed and more space left for the message --- see below on command length limitation. Further, PUSH_REPLY is currently comma delimited, so this will complicate push processing within openvpn. I would stick with the current space delimited format in management interface exchanges as its also consistent with the config file syntax. > > and > > - "echo message-notification,title,subtitle,text": Display the > "title", "subtitle", and "text" in the macOS "Notification Center" > [1]. The notification would persist until the user closes it. The > advantages with this as opposed to a non-modal popup window are that > it doesn't interrupt the user's workflow and honors a user's "do not > disturb" status (on macOS, anyway -- for example, while showing a > slideshow or other presentation). For Windows I think it would be a > "notification" in the taskbar area [2], but that's just a guess (I'm > not not sure that has the ability to show a subtitle). > If we want to get fancy, we could do: >- "echo window-url,url": Display a window with the contents of > "url" and a localized "OK" button. On macOS this would probably not be > a new browser window or tab, but would instead be a new Tunnelblick > window that displays what Safari would show (sandboxed to disallow > JavaScript and "file://"). > or even > > - "echo window-url,url1,url2,url3,button1text,button2text": Display a window with the contents of "url1" and two buttons labelled > button1text and button2text. If the window is dismissed with button1, > a GET request with url2 is made; if the window is dismissed with > button2 or for any other reason, a GET request with url3 is made. The > server would be responsible for localization of the button text. As an > example, this could allow the user to "agree" or "disagree" with the > VPN's terms of use; the VPN connection could then be terminated by the > server if the user disagreed (assuming the webserver and OpenVPN > server communicated this, of course). > > Encoding, Field Separators, and Escaping > > I propose the following _for_all_echo_commands_ (it would be nice to > be able to centralize parsing), which I think makes quoting > unnecessary and simplifies parsing. Quoting would still be done at the > "echo" level: > > echo "command-and-all-of-the-command's-arguments" > > I believe that's how echo is delivered now -- everything that follows echo is a single blob of text for openvpn, leaving its interpretation to the GUI. > * Everything is UTF-8-encoded. > All text within openvpn and config/ccd files and management communication are already utf-8, isn't it? So this should just work. > > * Length: I would code to handle anything less than a couple GB : > ). Probably this will be limited by what OpenVPN can store in the > "echo" buffer(s) but I'm not sure if there is a per-echo limit or an > overall limit on the size of the stored echos -- they get stored until > the GUI requests them. More p
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Sat, Nov 25, 2017 at 2:21 PM, Gert Doering wrote: > Hi, > > On Sat, Nov 25, 2017 at 12:27:10PM -0500, Selva Nair wrote: > > Thanks for summarising the status and proposals for echo commands. > > I missed something in your list, which *I* would like to see for > my users - a way to send a message to the GUI to display in a popup > window, intended for the users to see. > Yeah, this discussion started from a question about such a feature but was forgotten in this initial effort to "standardize" echo commands so that the same command would work on various UI's. Let's revive it for the selfish reason that I too am interested in having this :) > Examples could be stuff like > > "you are using a server that will be going away soon, please get >an updated profile from your system administrator" > > (like, when having to migrate due to CA rollover) > > or > > "your OpenVPN is old and has known security issues, please migrate >to version 2.4.4" > > or even > > "please change your Tunnelblick settings to enable OpenVPN 2.4, >for better performance and less battery usage (AEAD)" > > > (typically controlled by a --client-connect script on the server side > which looks at incoming IV_ attributes and decides what to send, whether > to send it on every connect or just once a week, etc. - but that's > somewhat out of scope, just to give a bit more background on what I think > how I'd use it) > > > Originally, I thought > > push echo 'my message' > > would do exactly this, but I've since learned that this is more > complicated, > so we'll need to define a message type > > push echo 'message this is my message' > How about echo "msg this is my message" OR echo "motd this is my message" IIRC, the max length of a line that openvpn command parser accepts is 255 bytes, so the above will allow ~237 bytes in the message, accounting for 5 bytes for adding "push ". We could just say any thing that the command parser will accept on the server side (if pushed) or client side is acceptable. For longer messages, we could allow concatenation of multiple messages as well as a echo "msg-title my title" to set a custom title for the message display window. > or something, agree on max length, encoding, dialog behaviour (shall it > be a tray message or non-modal dialog thing? do we want to have options to > select either?)... > As for encoding everything in the config file and lines transferred across the management interface are is assumed to be in utf-8, so use the same for this as well. That means the Windows GUI, e.g., will convert the message to ucs-16 before display. How to display the message need not be standardized and be left to the implementation as the best approach depends on the OS and will evolve with time. However, the GUI could have a user-defined setting that disables messages and/or opts for notify vs modal dialog etc. Again an implementation detail. When to display the message --- after successful connection or as soon as the echo is received? > Since I'm just a demanding user, I leave the specifics of that to you :-) > (I'm sure Arne will have some ideas as well) I want this feature too, I too go please ahead and demand and critique more so that something will get done sooner than later.. Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Sat, Nov 25, 2017 at 2:21 PM, Gert Doering wrote: > I missed something in your list, which *I* would like to see for > my users - a way to send a message to the GUI to display in a popup > window, intended for the users to see. > > Examples could be stuff like > > "you are using a server that will be going away soon, please get >an updated profile from your system administrator" > > (like, when having to migrate due to CA rollover) > > or > > "your OpenVPN is old and has known security issues, please migrate >to version 2.4.4" > > or even > > "please change your Tunnelblick settings to enable OpenVPN 2.4, >for better performance and less battery usage (AEAD)" > > > (typically controlled by a --client-connect script on the server side > which looks at incoming IV_ attributes and decides what to send, whether > to send it on every connect or just once a week, etc. - but that's > somewhat out of scope, just to give a bit more background on what I think > how I'd use it) > > > Originally, I thought > > push echo 'my message' > > would do exactly this, but I've since learned that this is more complicated, > so we'll need to define a message type > > push echo 'message this is my message' > > or something, agree on max length, encoding, dialog behaviour (shall it > be a tray message or non-modal dialog thing? do we want to have options to > select either?)... > > > Since I'm just a demanding user, I leave the specifics of that to you :-) > (I'm sure Arne will have some ideas as well) How about: - "echo message-window,title,subtitle,text": Display a non-modal popup window with title "title", subtitle "subtitle", text "text" and a localized "OK" button. and - "echo message-notification,title,subtitle,text": Display the "title", "subtitle", and "text" in the macOS "Notification Center" [1]. The notification would persist until the user closes it. The advantages with this as opposed to a non-modal popup window are that it doesn't interrupt the user's workflow and honors a user's "do not disturb" status (on macOS, anyway -- for example, while showing a slideshow or other presentation). For Windows I think it would be a "notification" in the taskbar area [2], but that's just a guess (I'm not not sure that has the ability to show a subtitle). If we want to get fancy, we could do: - "echo window-url,url": Display a window with the contents of "url" and a localized "OK" button. On macOS this would probably not be a new browser window or tab, but would instead be a new Tunnelblick window that displays what Safari would show (sandboxed to disallow JavaScript and "file://"). or even - "echo window-url,url1,url2,url3,button1text,button2text": Display a window with the contents of "url1" and two buttons labelled button1text and button2text. If the window is dismissed with button1, a GET request with url2 is made; if the window is dismissed with button2 or for any other reason, a GET request with url3 is made. The server would be responsible for localization of the button text. As an example, this could allow the user to "agree" or "disagree" with the VPN's terms of use; the VPN connection could then be terminated by the server if the user disagreed (assuming the webserver and OpenVPN server communicated this, of course). Encoding, Field Separators, and Escaping I propose the following _for_all_echo_commands_ (it would be nice to be able to centralize parsing), which I think makes quoting unnecessary and simplifies parsing. Quoting would still be done at the "echo" level: echo "command-and-all-of-the-command's-arguments" * Everything is UTF-8-encoded. * Length: I would code to handle anything less than a couple GB : ). Probably this will be limited by what OpenVPN can store in the "echo" buffer(s) but I'm not sure if there is a per-echo limit or an overall limit on the size of the stored echos -- they get stored until the GUI requests them. More practically, titles, subtitles, and notification text should be short so they display reasonably, but window text and URLs could be longer. * The field separator is a comma, just as the management interface uses commas to separate fields. (That's _not_compatible_ with Selva's proposed "setvar name value", which would need to become "setvar,name,value".) Spaces are good when the fields aren't likely to have spaces, but titles, subtitles, and text are more likely to have spaces than commas. * The escape character should be a backslash (0x5C). * Escape sequences would be limited to \\, \, and \n. Everything else that needs escaping would be escaped at and handled at a higher level. That may mean you need to double-backslash something like --echo "message-window,This is the title, This is the subtitle,This is the first line of text\\nThis is the second line of text.\\nThis is the third..." so what gets sent through the management interface has two "\n" sequences, but only one act
Re: [Openvpn-users] Management interface "echo" command standardization
Thanks! Comments below. On Sat, Nov 25, 2017 at 12:27 PM, Selva Nair wrote: > Hi, > > Thanks for summarising the status and proposals for echo commands. > > Comments below are based on what I have implemented in the > OpenVPN Windows GUI (Windows GUI in the following) and some > changes I've been working on. I refer to the client openvpn process > as the daemon or client daemon and the UI as Windows GUI or GUI. > > On Sat, Nov 25, 2017 at 10:24 AM, Jonathan K. Bullard > wrote: >> QUESTIONS ABOUT THE OPENVPN WINDOWS GUI: >> >> 1. In the OpenVPN Windows GUI, do "forget-passwords", >> "save-passwords", and "disable-save-passwords" only affect >> auth-user-pass passwords, or do they also affect auth-user-pass >> usernames and private-key passwords? > > > Both auth-user-pass and private key passwords are affected by each > of those commands. Currently the Windows GUI unconditionally saves > the username but that can and may change. So let's say those commands > affect all passwords and possibly username. I'll have Tunnelblick forget both passwords and the username. That's more like the "forget-passwords" command from the GUI to OpenVPN, which, as I understands it, forgets everything. > Should we support a more fine-grained set of commands as well? Say: > > echo save-auth-username > echo save-auth-password > echo save-private-key-password > > etc., in addition to the blanket 'echo save-passwords' ? I do not think so. Agreed. >> 2. Does OpenVPN Windows GUI send OpenVPN a "forget-passwords" >> command via the management interface when it receives an "echo >> forget-passwords" command? (Note: there are two different > > > No it does not. > >> >> "forget-passwords" commands, each in a different direction: a >> "forget-passwords" command from the GUI to the OpenVPN client, and an >> "echo forget-passwords" command from the OpenVPN client to the GUI.) > > > The Windows GUI considers the password saving in openvpn client daemon > to be completely decoupled from that in the GUI itself. Just as auth-nocache > in > the config has no effect on the password saving feature of the GUI, > 'echo forget-passwords' does not trigger a 'forget-passwords' directive from > the GUI to the client daemon. > > The 'forget-passwords' command can still be sent from the GUI to the > client daemon based on some preferences setting of the GUI or explicit > user action. AFAIK, the Windows GUI does not have an option to do that. That makes sense to me, so Tunnelblick won't send "forget-passwords" to the client daemon when it gets an "echo forget-passwords" command. >> 3. How would the "setenv" command work? Would it be done by >> modifying OpenVPN itself to add a management interface command for the >> GUI to tell OpenVPN to set an environment variable for scripts, >> similar to the way the OpenVPN --setenv option works? OpenVPN itself >> seems to be designed to protect the client computer from the server as >> well as the other way around. (For example,"--pull-filter ignore".) An >> "echo setenv" command would break that protection if it modifies >> variables which have been set by "setenv" in the configuration file or >> --setenv in the command line. > > > What is proposed is 'echo "setenv x y"' to set env variables in the GUI > (actually in the scripts run by the GUI -- see below). Ah, I misunderstood and thought it was setting them for client daemon's scripts. It makes much more sense to set them for scripts run by the GUI. (I didn't know the OpenVPN GUI had such scripts.) I'll have Tunnelblick do it for the scripts that Tunnelblick runs, mangling the names as you describe later. > I view all echo directives as aimed at the GUI and thus do not require any > support from the daemon. I suppose you have a different usage in mind. > Note that it is already possible for the server to set env variables in the > client daemon by pushing 'setenv-opt'. > > In other words, no change in openvpn daemon is needed as the effect is to > have > env variables set in script processes directly run by the GUI, not those run > by openvpn daemon. Thus, these variables are totally independent of those > set > in the daemon itself by 'setenv' and 'setenv-opt' directives, but some of > the safety > features used there could be borrowed (see below): > > The GUI will receive the echo command as > > ECHO,1101519562,setenv name value > > which the GUI will use to define an env variable "mangled(x) = y" in a > connection specific env-set. I propose to mangle the name as OPENVPN_x > as done for setenv-opt in the daemon. In that sense, an admin could think > of 'echo setenv ...' as the same as 'setenv-opt ...' but the former being > directed > to the GUI, the latter to the client daemon. > > Here is the commit message for this in my working branch for Windows GUI > (not yet in the official repo). Note that here 'process' means the GUI > process, > 'script' means a script run by the GUI etc. > > Support for 'setenv name var' using echo > >
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, On Sat, Nov 25, 2017 at 12:27:10PM -0500, Selva Nair wrote: > Thanks for summarising the status and proposals for echo commands. I missed something in your list, which *I* would like to see for my users - a way to send a message to the GUI to display in a popup window, intended for the users to see. Examples could be stuff like "you are using a server that will be going away soon, please get an updated profile from your system administrator" (like, when having to migrate due to CA rollover) or "your OpenVPN is old and has known security issues, please migrate to version 2.4.4" or even "please change your Tunnelblick settings to enable OpenVPN 2.4, for better performance and less battery usage (AEAD)" (typically controlled by a --client-connect script on the server side which looks at incoming IV_ attributes and decides what to send, whether to send it on every connect or just once a week, etc. - but that's somewhat out of scope, just to give a bit more background on what I think how I'd use it) Originally, I thought push echo 'my message' would do exactly this, but I've since learned that this is more complicated, so we'll need to define a message type push echo 'message this is my message' or something, agree on max length, encoding, dialog behaviour (shall it be a tray message or non-modal dialog thing? do we want to have options to select either?)... Since I'm just a demanding user, I leave the specifics of that to you :-) (I'm sure Arne will have some ideas as well) gert -- now what should I write here... Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Management interface "echo" command standardization
Hi, Thanks for summarising the status and proposals for echo commands. Comments below are based on what I have implemented in the OpenVPN Windows GUI (Windows GUI in the following) and some changes I've been working on. I refer to the client openvpn process as the daemon or client daemon and the UI as Windows GUI or GUI. On Sat, Nov 25, 2017 at 10:24 AM, Jonathan K. Bullard wrote: > Inspired by a thread [1] about sending a message from the server to > the client's GUI (and then displaying it to the user), I would like to > discuss standardizing the management interface's "echo" commands. It > would be nice if the OpenVPN Windows GUI, Tunnelblick, and other GUIs > implemented the commands in a compatible way. > > Although this may be of interest to the OpenVPN developers, I think it > is mostly of interest to OpenVPN users. (There isn't a list for > "OpenVPN administrators", which would be the best target.) > > > CURRENT STATUS OF THE ECHO COMMANDS > > Tunnelblick (I'm the developer) does not do anything with "echo" > commands; it doesn't ask the management interface for them. > > According to an email in the above-referenced thread from Selva Nair, > the OpenVPN Windows GUI currently implements the following: > > - "echo forget-passwords": delete passwords internally saved by the GUI > but do not disable the password save feature. Useful when pushed > from the server so that it gets processed after authentication. Also > see > management-notes.txt in openvpn docs. > > - "echo save-passwords": enables private-key and auth-user-pass > passwords > to be saved. Will be effective at startup only if present in the > config > file. If pushed from the server, will get used for subsequent > password prompts. Essentially this has the effect of presenting > the password > dialogs to the user with save-password checkbox selected. The > user may still > uncheck it during the dialog. > > And the following are being considered: > > - "echo disable-save-passwords": stops the user from being able to > save passwords. > > - "echo setenv": sets an environment variable for use by scripts. > > > QUESTIONS ABOUT THE OPENVPN WINDOWS GUI: > > 1. In the OpenVPN Windows GUI, do "forget-passwords", > "save-passwords", and "disable-save-passwords" only affect > auth-user-pass passwords, or do they also affect auth-user-pass > usernames and private-key passwords? > Both auth-user-pass and private key passwords are affected by each of those commands. Currently the Windows GUI unconditionally saves the username but that can and may change. So let's say those commands affect all passwords and possibly username. Should we support a more fine-grained set of commands as well? Say: echo save-auth-username echo save-auth-password echo save-private-key-password etc., in addition to the blanket 'echo save-passwords' ? I do not think so. > > 2. Does OpenVPN Windows GUI send OpenVPN a "forget-passwords" > command via the management interface when it receives an "echo > forget-passwords" command? (Note: there are two different > No it does not. > "forget-passwords" commands, each in a different direction: a > "forget-passwords" command from the GUI to the OpenVPN client, and an > "echo forget-passwords" command from the OpenVPN client to the GUI.) > The Windows GUI considers the password saving in openvpn client daemon to be completely decoupled from that in the GUI itself. Just as auth-nocache in the config has no effect on the password saving feature of the GUI, 'echo forget-passwords' does not trigger a 'forget-passwords' directive from the GUI to the client daemon. The 'forget-passwords' command can still be sent from the GUI to the client daemon based on some preferences setting of the GUI or explicit user action. AFAIK, the Windows GUI does not have an option to do that. > 3. How would the "setenv" command work? Would it be done by > modifying OpenVPN itself to add a management interface command for the > GUI to tell OpenVPN to set an environment variable for scripts, > similar to the way the OpenVPN --setenv option works? OpenVPN itself > seems to be designed to protect the client computer from the server as > well as the other way around. (For example,"--pull-filter ignore".) An > "echo setenv" command would break that protection if it modifies > variables which have been set by "setenv" in the configuration file or > --setenv in the command line. > What is proposed is 'echo "setenv x y"' to set env variables in the GUI (actually in the scripts run by the GUI -- see below). I view all echo directives as aimed at the GUI and thus do not require any support from the daemon. I suppose you have a different usage in mind. Note that it is already possible for the server to set env variables in the client daemon by pushing 'setenv-opt'. In other words, no change in openvpn daemon is needed as the effect is to have env variables set in script processes
[Openvpn-users] Management interface "echo" command standardization
Inspired by a thread [1] about sending a message from the server to the client's GUI (and then displaying it to the user), I would like to discuss standardizing the management interface's "echo" commands. It would be nice if the OpenVPN Windows GUI, Tunnelblick, and other GUIs implemented the commands in a compatible way. Although this may be of interest to the OpenVPN developers, I think it is mostly of interest to OpenVPN users. (There isn't a list for "OpenVPN administrators", which would be the best target.) CURRENT STATUS OF THE ECHO COMMANDS Tunnelblick (I'm the developer) does not do anything with "echo" commands; it doesn't ask the management interface for them. According to an email in the above-referenced thread from Selva Nair, the OpenVPN Windows GUI currently implements the following: - "echo forget-passwords": delete passwords internally saved by the GUI but do not disable the password save feature. Useful when pushed from the server so that it gets processed after authentication. Also see management-notes.txt in openvpn docs. - "echo save-passwords": enables private-key and auth-user-pass passwords to be saved. Will be effective at startup only if present in the config file. If pushed from the server, will get used for subsequent password prompts. Essentially this has the effect of presenting the password dialogs to the user with save-password checkbox selected. The user may still uncheck it during the dialog. And the following are being considered: - "echo disable-save-passwords": stops the user from being able to save passwords. - "echo setenv": sets an environment variable for use by scripts. QUESTIONS ABOUT THE OPENVPN WINDOWS GUI: 1. In the OpenVPN Windows GUI, do "forget-passwords", "save-passwords", and "disable-save-passwords" only affect auth-user-pass passwords, or do they also affect auth-user-pass usernames and private-key passwords? 2. Does OpenVPN Windows GUI send OpenVPN a "forget-passwords" command via the management interface when it receives an "echo forget-passwords" command? (Note: there are two different "forget-passwords" commands, each in a different direction: a "forget-passwords" command from the GUI to the OpenVPN client, and an "echo forget-passwords" command from the OpenVPN client to the GUI.) 3. How would the "setenv" command work? Would it be done by modifying OpenVPN itself to add a management interface command for the GUI to tell OpenVPN to set an environment variable for scripts, similar to the way the OpenVPN --setenv option works? OpenVPN itself seems to be designed to protect the client computer from the server as well as the other way around. (For example,"--pull-filter ignore".) An "echo setenv" command would break that protection if it modifies variables which have been set by "setenv" in the configuration file or --setenv in the command line. 4. Does "echo save-passwords" override a (presumed) global setting that disables it? 5. Will "echo disable-save-passwords" override a (presumed) global setting that enables it? COMMENTS ABOUT TUNNELBLICK: A. Tunnelblick can/will implement "echo disable-save-passwords" (in addition to Tunnelblick's existing mechanism for doing so). The user will not have a way to override this (even a user who is a computer administrator, but I want to think more about that and may change my mind). It would also forget saved passwords as if the "echo forget-passwords" had been received, because that is what the OpenVPN Windows GUI will do (according to Selva). B. Tunnelblick can/will implement "echo forget passwords" but I need clarification of exactly which "passwords" it affects (see question 1, above) and whether Tunnelblick should instruct OpenVPN to forget passwords, too. I'm leaning toward doing that because I don't think there is any other way for the server to tell the OpenVPN client to forget its passwords, so it could be useful. C. Tunnelblick can/will implement "echo save-passwords" only for configurations that are not set up to to *disallow* it. D. Tunnelblick can/will implement "echo setenv" assuming the management interface is modified to implement a command to do it or there is some other acceptable way to do it securely. E. Tunnelblick's settings can affect all configurations or individual configurations, and each setting can be "protected" so that only a computer administrator can change it. That protection is set up when Tunnelblick or the configuration is installed. Best regards, Jon Bullard [1] https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/20171120151612.nbipfbmui74pdadn%40charite.de/#msg36130244 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-users maili
