IMO, trying to restrict allowed operator characters based on their visual
similarity to other characters is folly. The unicode representation of a
character is an independent thing from its visual representation.
Because, ideally, I’d love to be able to do:
infix operator and: LogicalConjunctionPrecedence // or whatever the precedence
is called
func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
let truthyValue = true and false
That would make teaching simple predicate calculus much simpler. :)
Dave
> On Oct 3, 2017, at 10:43 AM, Félix Cloutier via swift-evolution
> <[email protected]> wrote:
>
>>
>> Le 2 oct. 2017 à 21:40, Chris Lattner <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> If you tried hard enough, you could probably create a variable that looks
>>> like it's shadowing one from an outer scope while it actually isn't, and
>>> use the two to confuse readers. This could trick people into thinking that
>>> some dangerous/backdoor code is actually good and safe, especially in the
>>> open-source world where you can't always trust your contributors.
>>>
>>> On one hand, other than the complexity of telling if two characters are
>>> lookalikes, I don't know why Αrray (GREEK CAPITAL LETTER ALPHA) and Array
>>> (LATIN CAPITAL LETTER A) should be considered different identifiers. On the
>>> other hand, I struggle to imagine the specifics of an exploit that uses
>>> that. You'd have to work pretty hard to assemble all the pieces of a
>>> backdoor in visually-similar variable names without arousing suspicion.
>>
>> 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.
>
>> 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.
>
> Félix
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
