Usage of String and UTF-8 guarantees

[Sh3Rm4n]

As of IEEE 80211-2020 9.4.2.2 SSID Element

When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes
the SSID element, or the Extended Capabilities of the source of the SSID information is known to include
the UTF-8 SSID capability based on a previously received Extended Capabilities element, the SSID is a
sequence of UTF-8 encoded code points. Otherwise, the character encoding of the octets in this SSID
element is unspecified.

As this crate does not do context aware parsing and the "Extended Capabilities" element is not parsed as well (see IEEE 80.211-2020 9.4.2.26 Bit 48), it shouldn't be assumed, that the SSID is valid UTF-8. There are also other instances of String, which might assume to much about the encoding.

What I propose is the usage of bstr for those instances.

[cathay4t]

So for the corner case of non-UTF8 SSID, we are forcing common UTF8 users to parse Vec<u8> or your suggested bstr into String in their own application.

Please prove this is not a corner case, then we can discuss on how to solve it.

[Sh3Rm4n]

Please prove this is not a corner case, then we can discuss on how to solve it.

AFAIK this is indeed very likely a corner case. I assume that this could only happen with very old devices and an older WiFi Standard.

It's up to you, if this uncommon case should be supported. If any of these devices with non UTF-8 SSIDs are detected via a scan the crate will always panic and the user can't do anything about it.

[surban]

Please prove this is not a corner case, then we can discuss on how to solve it.

While it's true that non-UTF-8 SSIDs are likely a corner case, it's precisely because we're dealing with untrusted input that all corner cases must be handled gracefully. Any assumption that leads to a panic opens the door to potential denial-of-service (DoS) vulnerabilities; in this case even exploitable remotely over the air without any authentication required.

Therefore, representing SSIDs as bstr::BStr (or at least Vec<u8>) rather than assuming UTF-8 semantics seems like the safer default. Applications that require a String can still perform lossy or fallible conversion explicitly, while the parsing crate itself should remain resilient under all spec-compliant (and even some malformed) inputs.

[cathay4t]

The pain is forcing every common user to suffer from converting from BStr to String for these old devices.

And ever worse, our API stability is now depend on bstr crate which I don't trust yet(what if they introduce 1000 dependency for MacOS support in the future).

Sorry, non-UTF8 SSID is not our target user.

[Sh3Rm4n]

The pain is forcing every common user to suffer from converting from BStr to String for these old devices.

I don't think this is as painful as it sounds. BStr already provides convenient abstractions that make conversion to String straightforward—comparable to (and sometimes better than) converting from OsString → String.

But the alternative would be to use Vec<u8> to support more than UTF-8.

And ever worse, our API stability is now depend on bstr crate which I don't trust yet

The bstr crate is widely used (200M+ downloads), small in scope, has only one required dependency, and is maintained by a well-established and trusted Rust OSS developer. From a risk perspective, this is one of the safer crates to depend on.

(what if they introduce 1000 dependency for MacOS support in the future).

Even in that hypothetical scenario, we are not obligated to update to such a version. We can simply pin or cap the dependency.

Is your hesitation mainly about depending on an external crate that we don't fully control?

Sorry, non-UTF8 SSID is not our target user.

If wl-nl8211 fully controls the origin of the strings, then restricting support to UTF-8 is perfectly reasonable. Assuming UTF-8 for all strings coming from the Linux kernel may also be acceptable, depending on the intended scope.

The issue, however, is that SSIDs and other elements defined in the 802.11 standard are not guaranteed to be UTF-8 (except in certain special cases noted in the original issue). If wl-nl80211 aims to implement the standard accurately, it should reflect this lack of guaranteed string encoding.

With the current implementation, any scanned device broadcasting a non-UTF-8 SSID (which is fully allowed by the standard) can cause the parser to panic. While this isn’t memory-unsafe, I would expect a low-level crate abstracting kernel APIs to handle such cases gracefully rather than crash.