[swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu]

On Mon, Jun 20, 2016 at 2:17 PM, João Pinheiro <swift-evolution at 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/

Unicode maintains a list of "confusable" characters. See here:
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 <svabox at gmail.com> wrote:
> >
> > Very interesting.
> >
> > Btw, IBM Swift Sandbox shows these spaces:
> > 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 t​est() { print("B") }
> >> func te​st() { print("C") }
> >>
> >> let abc = 1
> >> let a​bc = 2
> >> let ab​c = 3
> >>
> >> test()
> >> t​est()
> >> te​st()
> >>
> >> print(abc)
> >> print(a​bc)
> >> print(ab​c)
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160620/64336558/attachment.html>