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 > <swift-evolution@swift.org> wrote: > >> >> Le 2 oct. 2017 à 21:40, Chris Lattner <clatt...@nondot.org >> <mailto:clatt...@nondot.org>> a écrit : >> >>> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > 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