-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config parsing & push replies #257
Comments
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment we do not exactly implement the same config parsing as OpenVPN. I would say for local configuration files this is not too big a deal as long as we don't interpret "normal" configurations in an unexpected way. However, the configuration language is part of the protocol in the form of
PUSH_REPLY
so we must be careful not only for the sake of compatibility but also security.I wrote down some incomplete notes here:
18d4300#diff-ace9eb5f3f59d96c9b520197923cdaf51610a4b22c30cf8aa263233d3d3a7af9R883-R896
Another quirk is that the OpenVPN parser first tokenizes into "lines" which for
PUSH_REPLY
is morally equivalent toString.split_on_char ','
while for config files it splits on each line which includes the (carriage return and) line feed! Usually, this is fairly benign as it will mostly be interpreted as a separator of parameters, but the line feed (or carriage return) can sort-of be escaped with backslash meaning it's a way to embed a line feed (or carriage return) in a config directive but it's still treated as the end of the line.All in all there are many quirks of the OpenVPN configuration language that are not too easy to implement faithfully.
Instead of trying to faithfully implement all of the OpenVPN configuration language I suggest we decide on a sensible subset and otherwise reject configurations.
The text was updated successfully, but these errors were encountered: