Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
On 04/17/2012 11:42 PM, Martin Langhoff wrote: On Mon, Apr 16, 2012 at 3:33 AM, Simon Schampijer wrote: Thanks for the patch, looks good. I tested here with my AP that does announce in non utf-8 char and it works fine. Cool! Great stuff. What does your funny-chars AP read like in the UI with this patch? It displays the correct characters, the non ascii ones in non utf-8 format. Before Sugar was not able to display it, the Palette text was empty and you could not connect to it (dbus error). We have the short term fix, and now the long term fix is landing. Aye. And when we port the shell we can use the solution offered by nm-lib, so we are well equipped. About the nulls in the middle of the ESSID -- I hope that the kernel drivers know how to handle ESSIDs internally (hopefully using an array of bytes instead of a null-terminated string). Userland, OTOH, will be more prone to problems with nulls I suspect. The ESSID will come from a a config file (where usually nulls are not supported), or from a cmdline parameter, where's C-style string handling will have trouble with the nulls. m I hope so, too :/ Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
On Mon, Apr 16, 2012 at 3:33 AM, Simon Schampijer wrote: > Thanks for the patch, looks good. I tested here with my AP that does > announce in non utf-8 char and it works fine. Cool! Great stuff. What does your funny-chars AP read like in the UI with this patch? We have the short term fix, and now the long term fix is landing. Aye. About the nulls in the middle of the ESSID -- I hope that the kernel drivers know how to handle ESSIDs internally (hopefully using an array of bytes instead of a null-terminated string). Userland, OTOH, will be more prone to problems with nulls I suspect. The ESSID will come from a a config file (where usually nulls are not supported), or from a cmdline parameter, where's C-style string handling will have trouble with the nulls. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
Excerpts from Sascha Silbe's message of 2012-04-11 23:40:55 +0200: [embedded NUL in SSIDs] > Yes, that's the one case I wanted to test but couldn't (quickly) get > HostAP to do it. I'm now quite sure that with the current versions, I can't get either iwconfig (which can be used to set up a Prism 2.5 based AP at least in open and WEP modes) or hostapd (required for WPA on Prism 2.5 and for any AP mode on mac80211 based drivers) to use SSIDs with embedded NULs. iwconfig supports escaping for SSIDs, but using an embedded NUL causes truncation (possibly a driver bug). For hostapd, the configuration can only take unescaped, literal values. I've filed a corresponding feature request [1] upstream. Sascha [1] http://w1.fi/bugz/show_bug.cgi?id=441 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
On 04/02/2012 06:40 PM, Sascha Silbe wrote:
IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but
Sugar treated it as UTF-8 character data. While in most cases the SSID is
actually some human-readable string, there's neither a guarantee for that nor
does any (de-facto or de-jure) standard specify the encoding to use. As a
result, we'll encounter SSIDs in a large variety of encodings and will also
need to cope with arbitrary byte strings. Any assumption of a single (or in
fact any) character encoding is incorrect.
The D-Bus API of NetworkManager 0.9 [3] passes SSIDs as uninterpreted byte
strings (D-Bus signature "ay"). Before SSIDs can be displayed on screen, some
kind of interpretation must happen.
NetworkManager has a rather elaborate heuristic that takes the user locale into
account. In the future (i.e. when the NetworkManager client code in Sugar has
been ported to gobject-introspection) we may use nm_utils_ssid_to_utf8() [4],
but for now we're doing the following to allow the user to use non-UTF-8 APs at
all:
1. If the SSID is a valid character string consisting only of
printable characters in one of the following encodings (tried in
the given order), decode it accordingly:
UTF-8, ISO-8859-1, Windows-1251.
2. Return a hex dump of the SSID.
The first rule should cover the majority of current Sugar users and hopefully
all AP vendors will switch to UTF-8 eventually. In the meantime, the second
rule allows users to distinguish between several APs with SSIDs in unknown
encodings (or even using arbitrary byte sequences that don't _have_ a character
representation).
Tested:
- filtering on ASCII and non-ASCII parts of the name of and connecting to:
- an unsecured AP with a UTF-8 SSID ("äöü߀sugartest", HostAP)
- an unsecured AP with an ISO-8859-1 SSID ("äöüßsugartest", HostAP)
- an unsecured AP with a non-character SSID (0d:06:f0:0d, HostAP)
- a WEP-secured AP with a UTF-8 name ("äöü߀sugartest2", HostAP)
- a WEP-secured AP with an ISO-8859-1 name ("äöüßsugartest2", HostAP)
- a WEP-secured AP with a non-character SSID (0d:06:f0:0d, HostAP)
- a WPA-secured AP with an ASCII name (COTS AP)
In each case the name was displayed correctly in
a) the palette of the AP icon in the Neighbourhood,
b) the palette of the wireless network Frame device and
c) the title of the WLAN credentials (WEP/WPA passphrase) dialog (for
the WEP/WPA cases).
[1] https://bugs.sugarlabs.org/ticket/2023
[2] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[4]
http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8
Signed-off-by: Sascha Silbe
Thanks for the patch, looks good. I tested here with my AP that does
announce in non utf-8 char and it works fine.
I still don't see the hex-dump as needed but ok, if you have tested it,
I am happy with it.
I opened #3451 to track the porting to use "nm_utils_ssid_to_utf8" from
libnm.
Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
Excerpts from Martin Langhoff's message of 2012-04-10 21:43:20 +0200: > There is only one thing that still worries me. According to the spec, > the ESSID may also contain nulls in the middle of the array. I don't > know how NM handles such cases in its communication with nm-client via > d-bus. I don't know even how to setup an AP to broadcast an ESSID with > a null embedded. Yes, that's the one case I wanted to test but couldn't (quickly) get HostAP to do it. It would be good to check this on an XO to be sure it's not exploitable (DoS). Sugar (with my patch), Python and D-Bus should handle it correctly (see preview PNG data in data store metadata for a similar situation) and I'm more worried about drivers than about NM. That's also why I didn't put more energy into it (with my SL hat on - testing the 0.94 backport is still ongoing): we can't test the large number of different wireless drivers, even if we do manage to create a suitable test environment. I also doubt that anybody _not_ interested in breaking things (for fun or for profit) would set up an AP with an embedded-NUL SSID, and there's got to be a whole bunch of easier ways to hack an F14 system (which is the most recent distro most XOs in deployments are going to be running) than using a 32-byte octet sequence that may contain embedded NULs. It would be a rather interesting challenge, though. :) Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
On Tue, Apr 3, 2012 at 1:22 PM, Daniel Drake wrote: > Had a quick read through the patch, looks good. Same here. Thanks Sascha for this! There is only one thing that still worries me. According to the spec, the ESSID may also contain nulls in the middle of the array. I don't know how NM handles such cases in its communication with nm-client via d-bus. I don't know even how to setup an AP to broadcast an ESSID with a null embedded. Implementations -- AP and client side -- seem to handle the ESSOD as a string with unpredictable (and potentially mixed up) encoding but still as a string. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
Excerpts from Daniel Drake's message of 2012-04-03 19:22:52 +0200: > Had a quick read through the patch, looks good. Thanks for the review! Pushed as 7f8ba95 [1] to master. Backport to 0.94 prepared [2], but not tested yet. Sascha [1] https://git.sugarlabs.org/sugar/mainline/commit/7f8ba95a66780828531eba0494e004757bf45c71 [2] https://patchwork.sugarlabs.org/patch/1348/ -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
On Mon, Apr 2, 2012 at 10:40 AM, Sascha Silbe wrote: > IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but > Sugar treated it as UTF-8 character data. While in most cases the SSID is > actually some human-readable string, there's neither a guarantee for that nor > does any (de-facto or de-jure) standard specify the encoding to use. As a > result, we'll encounter SSIDs in a large variety of encodings and will also > need to cope with arbitrary byte strings. Any assumption of a single (or in > fact any) character encoding is incorrect. Had a quick read through the patch, looks good. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)
IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but
Sugar treated it as UTF-8 character data. While in most cases the SSID is
actually some human-readable string, there's neither a guarantee for that nor
does any (de-facto or de-jure) standard specify the encoding to use. As a
result, we'll encounter SSIDs in a large variety of encodings and will also
need to cope with arbitrary byte strings. Any assumption of a single (or in
fact any) character encoding is incorrect.
The D-Bus API of NetworkManager 0.9 [3] passes SSIDs as uninterpreted byte
strings (D-Bus signature "ay"). Before SSIDs can be displayed on screen, some
kind of interpretation must happen.
NetworkManager has a rather elaborate heuristic that takes the user locale into
account. In the future (i.e. when the NetworkManager client code in Sugar has
been ported to gobject-introspection) we may use nm_utils_ssid_to_utf8() [4],
but for now we're doing the following to allow the user to use non-UTF-8 APs at
all:
1. If the SSID is a valid character string consisting only of
printable characters in one of the following encodings (tried in
the given order), decode it accordingly:
UTF-8, ISO-8859-1, Windows-1251.
2. Return a hex dump of the SSID.
The first rule should cover the majority of current Sugar users and hopefully
all AP vendors will switch to UTF-8 eventually. In the meantime, the second
rule allows users to distinguish between several APs with SSIDs in unknown
encodings (or even using arbitrary byte sequences that don't _have_ a character
representation).
Tested:
- filtering on ASCII and non-ASCII parts of the name of and connecting to:
- an unsecured AP with a UTF-8 SSID ("äöü߀sugartest", HostAP)
- an unsecured AP with an ISO-8859-1 SSID ("äöüßsugartest", HostAP)
- an unsecured AP with a non-character SSID (0d:06:f0:0d, HostAP)
- a WEP-secured AP with a UTF-8 name ("äöü߀sugartest2", HostAP)
- a WEP-secured AP with an ISO-8859-1 name ("äöüßsugartest2", HostAP)
- a WEP-secured AP with a non-character SSID (0d:06:f0:0d, HostAP)
- a WPA-secured AP with an ASCII name (COTS AP)
In each case the name was displayed correctly in
a) the palette of the AP icon in the Neighbourhood,
b) the palette of the wireless network Frame device and
c) the title of the WLAN credentials (WEP/WPA passphrase) dialog (for
the WEP/WPA cases).
[1] https://bugs.sugarlabs.org/ticket/2023
[2] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[4]
http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8
Signed-off-by: Sascha Silbe
---
extensions/deviceicon/network.py | 17 +++-
src/jarabe/desktop/keydialog.py|5 ++-
src/jarabe/desktop/meshbox.py |4 +-
src/jarabe/desktop/networkviews.py | 33 ---
src/jarabe/model/adhoc.py |6 ++--
src/jarabe/model/network.py| 49 +--
6 files changed, 81 insertions(+), 33 deletions(-)
diff --git a/extensions/deviceicon/network.py b/extensions/deviceicon/network.py
index 1beeb88..09a3abb 100644
--- a/extensions/deviceicon/network.py
+++ b/extensions/deviceicon/network.py
@@ -374,7 +374,8 @@ class WirelessDeviceView(ToolButton):
self._device = device
self._device_props = None
self._flags = 0
-self._name = ''
+self._ssid = ''
+self._display_name = ''
self._mode = network.NM_802_11_MODE_UNKNOWN
self._strength = 0
self._frequency = 0
@@ -394,7 +395,7 @@ class WirelessDeviceView(ToolButton):
self._icon.show()
self.set_palette_invoker(FrameWidgetInvoker(self))
-self._palette = WirelessPalette(self._name)
+self._palette = WirelessPalette(self._display_name)
self._palette.connect('deactivate-connection',
self.__deactivate_connection_cb)
self.set_palette(self._palette)
@@ -471,7 +472,8 @@ class WirelessDeviceView(ToolButton):
self._mode = properties['Mode']
self._color = None
if 'Ssid' in properties:
-self._name = properties['Ssid']
+self._ssid = properties['Ssid']
+self._display_name = network.ssid_to_display_name(self._ssid)
self._color = None
if 'Strength' in properties:
self._strength = properties['Strength']
@@ -482,11 +484,11 @@ class WirelessDeviceView(ToolButton):
if self._color == None:
if self._mode == network.NM_802_11_MODE_ADHOC and \
-network.is_sugar_adhoc_network(self._name):
+network.is_sugar_adhoc_network(self._ssid):
self._color = profile.get_color()
else:
sha_hash = hashlib.sha1()
-data = self._name + hex(self._flags)
+data =
