On Oct 3, 2017, at 9:43 AM, Félix Cloutier <felixclout...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
