I agree that treating zero-width spaces as non-existent would be a possible solution, but I think it would make more sense to consider it as white space and thus not admissible in identifier names. I'm not sure of what the best way to handle left-to-right and right-to-left markers would be. Does it make sense to allow mixed text orientation in identifiers?
Removing ambiguity between unicode confusables is a much more complicated issue which implies defining a canonical unicode representation for identifiers and a way to resolve them. It would also make it impractical to use certain valid mathematical symbols as identifiers. João Pinheiro > On 20 Jun 2016, at 20:23, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Mon, Jun 20, 2016 at 2:17 PM, João Pinheiro <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>> wrote: > Nice feature in the IBM Swift Sandbox. Xcode doesn't display zero-width > spaces either so the identifier names look exactly the same. > > The issue with left-to-right and right-to-left markers is interesting and has > previously been exploited in email phishing attacks. > > It would be possible to highlight invisible characters in Xcode as a stopgap > measure, but that doesn't solve the problem for developers using other > editors or in other platforms. I think it would be a better idea to sanitise > the set of allowed (or prohibited) characters for identifiers at the language > level. > > This is a potential security problem, but no need try to invent an ad-hoc > solution here, particularly one as drastic as prohibiting characters. The > same security considerations are applicable elsewhere and there's a lot of > work about Unicode security. See here: http://www.unicode.org/reports/tr39/ > <http://www.unicode.org/reports/tr39/> > > Unicode maintains a list of "confusable" characters. See here: > http://www.unicode.org/Public/security/latest/confusables.txt > <http://www.unicode.org/Public/security/latest/confusables.txt> > > It should be sufficient to regard confusables as the same glyph for the > purpose of identifier names; zero-width and invisible marks would then be > regarded as non-existent, so that `test` and `t[invisible glyph]est` would > refer to the same variable. > > > Sincerely, > João Pinheiro > > > > On 20 Jun 2016, at 19:26, Vladimir.S <sva...@gmail.com > > <mailto:sva...@gmail.com>> wrote: > > > > Very interesting. > > > > Btw, IBM Swift Sandbox shows these spaces: > > https://swiftlang.ng.bluemix.net/ <https://swiftlang.ng.bluemix.net/> > > But my mail client does not - i.e. I saw exactly the same "test"&"abc" > > > > Also, I read about some issues with left-to-right and right-to-left markers > > that also somehow change the actual text of source - i.e. you see one text, > > but when it compiles - it works not as expected. I.e. viewer/editor > > processes these special codes and show you one text, but compiler treats > > text in another way. > > > > I believe it is a potential security problem that all unicode chars are > > allowed for variables/func names in Swift. IMO We definitely should limit > > allowed charset for identifiers in sources. > > > > On 20.06.2016 20:51, João Pinheiro via swift-evolution wrote: > >> Recently there has been a screenshot going around Twitter about C++ > >> allowing zero-width spaces in variable names. Swift also suffers from this > >> problem which can be abused to create ambiguous, misleading, and > >> potentially obfuscate nefarious code. > >> > >> I would like to propose a change to prohibit the use of invisible > >> characters in identifier names. > >> > >> I'm including an example of problematic code at the bottom of this email. > >> > >> Sincerely, > >> João Pinheiro > >> > >> > >> /* The output for this code is: > >> A > >> B > >> C > >> 1 > >> 2 > >> 3 > >> */ > >> > >> func test() { print("A") } > >> func test() { print("B") } > >> func test() { print("C") } > >> > >> let abc = 1 > >> let abc = 2 > >> let abc = 3 > >> > >> test() > >> test() > >> test() > >> > >> print(abc) > >> print(abc) > >> print(abc) > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> > >> https://lists.swift.org/mailman/listinfo/swift-evolution > >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
