On Sunday, 14 May 2017 at 21:01:40 UTC, Jack Stouffer wrote:
> On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote:
>> b) If you want to do things that C allows you to do, then Rust is no more safer than C.
>
> That's the entire bloody point isn't it? Maybe you shouldn't be doing a lot of the things that C allows you to do.

Hi, I think you are missing the point. I am talking here about things you need to do rather than writing code just for the heck of it.

On 5/5/2017 11:26 PM, Joakim wrote:
> Walter: I believe memory safety will kill C.

I can't find any definitive explanation of what the Wannacry exploit is. One person told me it was an overflow bug, another that it was truncation from converting 32 to 16 bits.

Anyhow, the Wannacry disaster looks to be a very expensive lesson in using memory unsafe languages for critical software. I know Microsoft has worked for years to use their own C which is memory safer, apparently it is not enough.

https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/

On Tuesday, 16 May 2017 at 15:19:54 UTC, Walter Bright wrote:
> On 5/5/2017 11:26 PM, Joakim wrote:
>> Walter: I believe memory safety will kill C.
>
> I can't find any definitive explanation of what the Wannacry exploit is. One person told me it was an overflow bug, another that it was truncation from converting 32 to 16 bits.
>
> Anyhow, the Wannacry disaster looks to be a very expensive lesson in using memory unsafe languages for critical software. I know Microsoft has worked for years to use their own C which is memory safer, apparently it is not enough.
>
> https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/

I happened to be reading this blog post concerning the issue today:

https://www.troyhunt.com/dont-tell-people-to-turn-off-windows-update-just-dont/

It links to this official MS page from a couple months ago, which lists several CVE entries, which explicitly say they're different exploits:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Googling for that security update turns up this script, which claims a buffer overflow, but that could be just one of the holes:

https://github.com/RiskSense-Ops/MS17-010/blob/master/exploits/eternalblue/ms17_010_eternalblue.rb

I don't believe MS has disclosed the exact exploits, so it would depend on someone reversing the updates and since there are so many, they're likely different types.

For those like Scott who say C has survived this long, I say it isn't unprecedented for tech with fairly well-known design flaws to last much longer than it should, until a crisis springing from those flaws finally kills it off.  People usually ignore the potential problems until it blows up in front of their face.

I agree that this current constant security crisis, now that everything's on the internet, will kill off a lot of old tech, including C.  It is one of the reasons IoT is currently stillborn.  It is the biggest flaw in Android, where you're selling a billion+ mobile devices a year, and almost none of them get any security updates:

https://arstechnica.com/gadgets/2017/05/op-ed-google-should-take-full-control-of-androids-security-updates/

It will get a lot worse before it gets better, because it has been neglected for so long. :|

On 5/16/17 11:19 AM, Walter Bright wrote:
> On 5/5/2017 11:26 PM, Joakim wrote:
>> Walter: I believe memory safety will kill C.
>
> I can't find any definitive explanation of what the Wannacry exploit is.
> One person told me it was an overflow bug, another that it was
> truncation from converting 32 to 16 bits.
>
> Anyhow, the Wannacry disaster looks to be a very expensive lesson in
> using memory unsafe languages for critical software. I know Microsoft
> has worked for years to use their own C which is memory safer,
> apparently it is not enough.
>
> https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/
>

Scott: "I am skeptical of the claim that memory safety is going to kill [C] off because it has been known that this is not a memory safe language for decades."

Dylan: "Do you think that maybe Walter and Andrei planted the memory safety topic just to try to kill C?"

Scott: "You know that would be like them..."

1 week later: WanaCry.  Both Walter and WanaCry start with W. Hm....

-Steve

On 5/16/2017 10:29 AM, Steven Schveighoffer wrote:
> 1 week later: WanaCry.  Both Walter and WanaCry start with W. Hm....

No need to breed mosquitos to promote a cure for malaria :-)

On Friday, 12 May 2017 at 18:52:43 UTC, Joakim wrote:
> On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:
>> On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
>>> [...]
>>
>> Hm, Sociomantic removes the live captures the next day?
>>
>> One request: Chop the panel discussion into one clip per question/topic, please. Alternatively, provide some means to easily jump to the start of each question.
>
> Video of the exchange is now back up:
>
> https://www.youtube.com/watch?v=Lo6Q2vB9AAg#t=24m37s
>
> Question now starts at 22m:19s mark.

Hmm, this talk has become the most-viewed from this DConf, by far beating Scott's keynote.  Wonder how, as this seems to be the only link to it, hasn't been posted on reddit/HN.  I guess people like panels, the process panel last year is one of the most viewed videos also.

On 5/17/2017 3:21 AM, Joakim wrote:
> Hmm, this talk has become the most-viewed from this DConf, by far beating
> Scott's keynote.  Wonder how, as this seems to be the only link to it, hasn't
> been posted on reddit/HN.  I guess people like panels, the process panel last
> year is one of the most viewed videos also.

I received -2 net votes on Hackernews for suggesting that the takeaway from the WannaCry fiasco for developers should be to use memory safe languages.

Maybe the larger community isn't punished enough yet.

On Wed, May 17, 2017 at 01:41:43PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/17/2017 3:21 AM, Joakim wrote:
> > Hmm, this talk has become the most-viewed from this DConf, by far beating Scott's keynote.  Wonder how, as this seems to be the only link to it, hasn't been posted on reddit/HN.  I guess people like panels, the process panel last year is one of the most viewed videos also.
> 
> I received -2 net votes on Hackernews for suggesting that the takeaway from the WannaCry fiasco for developers should be to use memory safe languages.
> 
> Maybe the larger community isn't punished enough yet.

People aren't willing to accept that their cherished choice of language may have been the wrong one, especially if they have invested much of their lives in mastering said language.

Though from what I can tell, the WannaCry fiasco is more than merely a matter of memory safety; it also involves backdoors. Backdoors are always considered "safe" by the people who implement them, but unfortunately, time and time again history has proven that backdoors always get found by the wrong people, usually with disastrous consequences.  Security by obscurity does not work, yet people continue to believe it does.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".

On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
> People aren't willing to accept that their cherished choice of language
> may have been the wrong one, especially if they have invested much of
> their lives in mastering said language.

It may not be the developers that initiate this change. It'll be the managers and the customers who force the issue - as those are the people who'll pay the bill for the problems.

> Though from what I can tell, the WannaCry fiasco is more than merely a
> matter of memory safety;

It may very well be. But if memory safety is part of the problem, then it is part of the solution.

On Wed, May 17, 2017 at 04:16:59PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/17/2017 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
> > People aren't willing to accept that their cherished choice of language may have been the wrong one, especially if they have invested much of their lives in mastering said language.
> 
> It may not be the developers that initiate this change. It'll be the managers and the customers who force the issue - as those are the people who'll pay the bill for the problems.

That may or may not force a shift to a different language. In fact, the odds are heavily stacked against a language change. Most management are concerned (and in many cases, rightly so) about the cost of rewriting decades-old "proven" software as opposed to merely plugging the holes in the existing software.  As long as they have enough coders plugging away at the bugs, they're likely to be inclined to say "good enough".

The only way this will change is if a nasty enough exploit causes a large enough incident, and if it's something that shakes the very foundations of practically all code in that language -- say a fundamental flaw in the C standard library or something of that scale that has no easy fix except rewriting major chunks of all code that uses the C library.  Either that, or if a continuous stream of high-visibility exploits occur over an extended period of time, all related to flaws in C or the C standard library, such that people eventually grow disgusted enough at yet another buffer overflow or yet another stack overflow, etc., that they seriously start considering alternatives.

Barring these extreme scenarios, I see the more likely outcome is an increasing adoption of safe coding conventions that may help in the short term, but ultimately unable to address fundamental language design issues.

Perhaps what will eventually cause a change is education: if the next generation of programmers are educated to be aware of security issues and language design issues, they may be more inclined to choose a memory-safe language when they are given a choice. Eventually, if they become the decision-makers, that is when the shift will happen.


> > Though from what I can tell, the WannaCry fiasco is more than merely a matter of memory safety;
> 
> It may very well be. But if memory safety is part of the problem, then it is part of the solution.

Memory safety is only part of the story.  I'm tempted to quote you saying that it's only plugging one hole in a cheesegrater, but in this case it's a pretty darn big hole. :-P

But there are other issues that memory safety doesn't even begin to address, like race conditions, resource leakage (leading to DoS attacks), improper use (or lack of use) of cryptographically-secure primitives, access control, data sanitization, leakage of sensitive data, inherently insecure designs (e.g., backdoors), etc..

After having been involved in a major code audit project at my work, I'm increasingly of the opinion that the vast majority of coders have no idea how to write secure code (or they are just too indifferent to bother), and that the vast majority of non-trivial codebases running our present-day systems right now are riddled chockful of security holes just waiting for someone to devise an exploit for. Only some of these flaws are related to memory safety.


T

-- 
Once bitten, twice cry...