Fantastic exchange from DConf

[Steven Schveighoffer via Digitalmars-d]

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