I was referring specifically to security footguns like having a string eval. While one can construct code in which that is the critical error that led to a security vulnerability, that can be said about any confusing bit of code in any language, and I would not judge that to especially lead to security issues.
This sets the bar ludicrously low for "security footgun". If this is a "security footgun" then what is string evaluation in a dynamic scripting language, a "security foot-nuke"?
Granted, there is no sharp line that can be drawn, but given my personal career I'd say I've encountered it personally at least once is a reasonable bar, if not quite excessively low. (tptacek would have to set the bar somewhere else, given his career.) Concurrency issues causing a security issue because of type confusion on an interface in a Go program is not a "every time I crack open a program, oi, this security vulnerability again" like bad HTML escaping or passing things straight to a shell. I mean, "concurrency issues causing type confusion on an interface" is already not something I've ever personally witnessed, let alone it actually being a security issue rather than a difficult-to-trace panic issue.
And I will reiterate, I already say that any bug can become a security issue in the right context. That doesn't make them all "security footguns".
> This sets the bar ludicrously low for "security footgun". If this is a "security footgun" then what is string evaluation in a dynamic scripting language, a "security foot-nuke"?
Not really. Apart from dangerous serialization formats (e.g. Python's "pickle") it's not at all easy to eval a string in modern scripting languages.
String evals are also not widely used anymore.
This actually is a security footgun. In Java or C# you can't get security issues by trying to update a reference from multiple threads, because it's always atomic. In Go you can create type confusion because interface pointer updates are not atomic.