On Wed, 2016-03-02 at 14:37 -0600, Dan Williams wrote:
On Wed, 2016-03-02 at 12:53 +0100, Thomas Haller wrote:Openvpn treats ovpn files as ASCII configuration file and does not care about a specific certain encoding. As such, only encodings that are an extension of ASCII can work at all (like iso8859-* or utf8). We should not try to handle configuration files that cannot even be handled by openvpn itself. As regular options must be ASCII-compatbile, the encoding only matters for filenames and inline-blobs. Openvpn itself doesn't care about encoding of filenames and passes them directly to the system functions (open, access). The same is true for glib, which expects paths in "GLib file encoding". Nowaways, most Linux filesystems use utf8 encoding for paths. Therefore, if we would know the encoding of the file, we probably would want to convert the paths to utf8. However, how do we guess the right encoding? And what if the user *really* meant what is written in the configuration file? Note, that openvpn doesn't support escape sequences like "\344", thus, if the user really wanted to specify such a character, he is only able to do so if we don't mess with the encoding. Inline blobs usually are ASCII/base64 encoded. If they happen to be in a different encoding, we still want to preserve the original blob and not guess and convert encodings. The only sane option is ignoring the encoding and pretend it is ASCII compatible. Who writes non-utf8 configuration files anyway?We have to make sure string data we pass through D-Bus (like in the connection properties) is UTF-8 though. So it doesn't need to be converted or validated at some point, or dbus will kick the editor/whatever off the bus when it tries to send the invalid data to NM.
very good point. So, this is going to be a bit larger work. Let's move discussion to bug https://bugzilla.gnome.org/show_bug.cgi?id=763039 Please review th/utf8safe-bgo763039 Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part