On 5/18/17 12:40 AM, H. S. Teoh via Digitalmars-d wrote:
On Wed, May 17, 2017 at 08:58:31PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On 5/17/17 8:27 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
What will cause a shift is a continuous business loss.
If business A and B are competing in the same space, and business A
has a larger market share, but experiences a customer data breach.
Business B consumes many of A's customers, takes over the market, and
it turns out that the reason B wasn't affected was that they used a
memory-safe language.
The business cases like this will continue to pile up until it will be
considered ignorant to use a non-memory safe language. It will be even
more obvious when companies like B are much smaller and less funded
than companies like A, but can still overtake them because of the
advantage.
This is a possible scenario, but I don't see it being particularly
likely, because in terms of data breaches, memory safety is only part of
the equation. Other factors will also come into play in determining the
overall susceptibility of a system. Things like secure coding practices,
and by that I include more than just memory safety, such as resource
management, proper use of cryptographic technology, privilege
separation, access control, data sanitation, etc.. In spite of C's
flaws, it *is* still possible to create a relatively secure system in C.
It's harder, no argument about that, but possible. It depends on how
the company implements secure coding practices (or not). In a memory
safe language you can still make blunders that allow breaches like SQL
injection in spite of memory safety.
Of course. But what business people would see is a huge company like
facebook being marginalized by a small startup, and having the analysts
say "well, it's mostly because they used Rust/D". The game would be over
at that point, regardless of the technical details of the "true" root cause.
Note: I just use facebook as an example of a company that is so large
and pervasive that everyone thinks they are unkillable, I don't really
think the strawman scenario above is likely. Remember the old saying,
"Nobody ever got fired for picking IBM"? How relevant is that today?
Nevertheless, there is still an ongoing stream of exploits and security
incidents in the web programming world largely driven by supposedly
memory-safe languages like Java or Javascript. (Well, there is that
disaster called PHP that's still prevalent on the web, maybe that
accounts for some percentage of these exploits. But that's mostly in the
implementation of PHP rather than the language itself, since AFAIK it
doesn't let you manipulate memory directly in an unsafe way like C does.
But it does let you do a lot of other stupid things, security-wise, that
will still pose problems even though it's technically memory-safe.
That's why I said, memory safety only goes so far -- you need a lot more
than that to stand in the face of today's security threats.)
Speaking of "memory safe" languages like PHP whose implementation is not
necessarily memory safe, there is a danger here also in how D is moving
towards memory safety. We still allow unsafe operations inside @safe
code, using @trusted. This is a necessary evil, but it's so very
important that the base libraries (druntime and phobos) keep this to a
minimum, and that we review those @trusted blocks to death.
-Steve
