[swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Chris Lattner]

On Oct 3, 2017, at 9:43 AM, Félix Cloutier <felixcloutier at icloud.com> wrote:
>> I don’t think this is something we have to try hard to avoid.  It is true that some characters look similar, particularly in some fonts, but this isn’t new:
>> 
>>   let a1 = 42
>>   let al = 12
>>   let b = al + a1 
> 
> There is a fundamental difference between similar characters and characters that are meant to be visually identical. People judge the quality of a font by its Unicode support, and that means that only "low-quality" fonts would render, say, LATIN CAPITAL LETTER T and GREEK CAPITAL LETTER TAU differently.

As Dave DeLong mentions downthread, it really isn’t different.  Different codepoints can look similar in some fonts and different in other fonts.  That is reality for a broad range of codepoints. 

All I’m saying is that it isn’t a priority (to me) to “solve” this problem.

> 
>> If there were real code that was maliciously shadowing to try to cause confusion, then you have a more serious problem on your hands than someone accidentally misunderstanding which one to use.
> 
> I'm not sure I understand. If the "more serious problem" you're talking about is that your popular project is a valuable target to subvert, then there is no question that being backdoored would be more serious than people not reading your code right. I don't see how it pushes the problem out of scope, though.
> 
> As a security guy, I take my role of thinking about how anything can be abused very seriously. Backdoored open source projects turn up every now and then.
> 
> This code is backdoored. I challenge you to spot the bug:
> 
> func shellEscape(_ args: [String]) -> [String]?
> func isWhitelisted(_ tool: String) -> Bool
> 
> func execute(externalTool: String, parameters: [String]) {
>     if isWhitelisted(externalTool), let pаrameters = shellEscape(parameters) {
>         print("Running tool \(pаrameters[0])")"
>         system(parameters.joined(separator: " "))
>     }
> }

>> All I’m saying is that we shouldn’t complicate the design to solve this problem (IMO).  If it falls out of the solution somehow (e.g. just disallow invisible characters) then that’s great of course!
> 
> How did you identify the bug in the snippet from above? Is it practical enough that you would, for instance, recommend that the server group do that test on every PR that they receive going forward?
> 
> I think that it's hard to build something meaningful without making it look suspicious. It's already kind of fishy that my shellEscape function returns an Optional, and people will eventually figure out that the parameters are not, in fact, shell-escaped. Still, I feel that it should be recognized that security is more than buffer overflows and integer overflows, and if there ever is an underhanded Swift code contest, that'll be my entry.

I don’t see the bug, but I assume you’re doing something evil with “parameters" not getting shell escaped.  

Seriously, I get the issue you’re trying to draw attention to, and I respect the fact that good security folks are paranoid :-).  That doesn’t make “fixing this” a high priority in itself though.  We have to weight the cost and benefit of solving this.  If “solving” this problem makes swift substantially more complex, difficult to specify, or difficult to maintain, or if it prevents this proposal from going through, then MHO is that this is not worth fixing.

The rationale is that if you have evil actors trying to subvert your code, there are a lot easier ways to do so than through this mechanism.  Additionally, if you are someone who cares so much, it is trivial to define additional checker tools outside of the compiler to check for such things - just as some people enforce house style rules (like no use of “x!”) in external tools.  All problems do not have to be solved through language design.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/81ca8c2b/attachment.html>