3 ms·

I don't believe that, you mention this because you put 100% trust on the runtime. When I see syntax like: var array=something[4...$] I don't see security there,

I don't believe that, you mention this because you put 100% trust on the runtime. When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. So Sure, RIGHT NOW the runtime might be safe from scrutiny, but is it because its SAFE or just not as such a high profile, just yet? On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.

klez 7y ago
The difference is that if the bug is in the runtime you have to fix one place and everyone downstream gets that. If you solve one such bug in curl, you solved it just in curl. EDIT: I thought about it a bit more and realized it cuts both ways. If you have an RCE in a standard library a lot of programs get an RCE for free while it's not patched. So yeah, a bit of a mixed bag.
- ppseafield 7y ago
  There's also the difference that, in a GC'd language, you don't have both the language authors and the language users both competing to put these kinds of bugs in their software. :)
  - tomatocracy 7y ago
    True, but when you want to interface between code written in two different GC'd languages then you can get similar problems if you're not careful. As the number and use of these various next generation languages proliferates, I suspect we might start to see more of that kind of thing appearing over time.
- oconnor663 7y ago
  I posted a bit more beside this comment, but I think the difference isn't so much updates or code review but rather the design intention of the language. A language like Java or Python or Rust is designed for every operation to produce some defined behavior, and you can't generally trigger RCE unless you call some function like `unsafePerilousDangerZone(heinousRawPtr)`. Those design defaults bubbles up through libraries written in those languages, so that when you use other people's code and make a mistake, the result is either a crash or an unfortunate-but-at-least-well-defined logic bug. The opposite is true in C and C++, and that bubbles up through the libraries in those languages too.
- CaptainMarvel 7y ago
  [[Off-Topic - Sorry!]] Hi Klez, I determined this to be the only way to get in touch regarding a previous discussion we had on Blendle [0] as I can no longer reply on that thread. This was back in 2017 so they may have fixed their issues. Alexander Klöpping <alexander.klopping@blendle.com> emailed me, I'll grant it was a generic welcome email, asking for feedback. I took the opportunity to email back informing him of the problems with using my email address [1]. I don't recall the problem now, but it seems they accepted my email address but then later rejected it during the sign-up process (as I clearly received an email correctly...). I no longer have their response, but from memory, it was a different customer service person, and they rejected the idea that they had any problem AND/OR explicitly said they weren't going to make any changes. Oh, and they sent that response to the email that I explicitly said wouldn't work (it automatically gets sent to the trash to be deleted which is also why I don't have it any more). Their rejection of fixing their service is what made me decide to put Blendle in the trash category. [0]: https://news.ycombinator.com/item?id=20138213 https://news.ycombinator.com/item?id=20138213 [1]: My email, sent from X+Y@gmail.com Dear Alexander Klöpping, When I first heard about Blendle I was excited at the concept of being able to read high-quality journalism from multiple different sources through one - ad-free - platform and one reasonably-priced payment system, and so I signed up for the beta. I successfully started the process of joining Blendle by unlocking and selecting some preferences. However, I have been unable to proceed past entering my email address, X+Y@gmail.com. I should make it clear that the email address X@gmail.com cannot be used. Could you please assist me and help me get started with Blendle? Best, [redacted]
  - klez 7y ago
    Hey, thanks for replying to that question :) I guess I should give some way to contact me in my profile for cases like this.
oconnor663 7y ago
> When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. The runtime (whichever one that is) is safe because its behavior is defined by design for all inputs. Yes there could be a bug, but the design is that all inputs should be defined, and doing something for any given input isn't rocket science. Out of bounds array indexes either panic/throw or return empty lists. That can lead to crashes and logic errors, sure, or maybe DOS attacks, but it cannot lead to undefined behavior or remote code execution. That's a world of difference. C and C++ by design expose heaps of undefined behavior to the caller. The tools for detecting UB are imperfect and don't work if the relevant inputs never show up in test cases. Even when veteran C coders develop the techniques and habits that let them write correct C, mistakes tend to show up at the integration points between libraries written by different people with different techniques and habits (https://youtu.be/HgtRAbE1nBM?t=2344 https://youtu.be/HgtRAbE1nBM?t=2344).
Groxx 7y ago
That's kinda like claiming "a single implementation that everyone uses is no more secure/stable than a million independent implementations", which is fairly ridiculous. It's not (just) "pushing the problem further under the carpet", it's centralizing risk and attention and fixes, which does work out quite well in practice.
AgentME 7y ago
>all I see is someone pushing the problem further under the carpet, into the runtime. How often are there bugs in language runtimes that cause vulnerabilities in programs that are exploitable by users putting in different data into an otherwise secure program? (I'm not talking about the case where the runtime has a sandbox that breaks when the user loads bad code into it; this is a use-case C/C++ don't even try to address so that would be comparing different things. I'm talking about cases where someone is running a program that communicates over the network and the program's own code is written correctly, but a problem in the runtime makes it so the program is vulnerable to remote code execution.) The main example I can think of like that was Shellshock, which was horrible, but I would never have held up Bash as an example of a safe language. Bash has always been on my short list next to C and C++ of languages to avoid because of how easy and common it is to make mistakes that are practically unnoticeable in review. >On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language. Junior developers can write a buggy mess in any language. C/C++ are practically the only popular languages where a junior developer can accidentally write a backdoor in average-looking code that doesn't use any APIs. I can tolerate some bugs in my software sometimes, but exploitable bugs are an entirely different thing to me.
jcranmer 7y ago
Let's say there's a trillion lines of code written in C, and a million lines of code written in the runtime for a safe language where the trust is being pushed into. That means you can throw a million times the resources at finding and fixing the bugs in the runtime. While the payoff ratio is going to be far less than linear, you're looking at the C code being buggier and problematic by 100×. Actually, the situation for C is even worse than that makes it appear. C, both the language itself and the infrastructure ecosystem around it, actively fight you when you try to build and use tools to proactively find problems. The only tooling that tends to be effective in practice is built on dynamic analysis, which means that you can only be in confident in the safety of your code as you can be in your testing regime--and there are very few, if any, codebases that have a strong enough testing regime. We, as an industry, have almost 50 years of coding in C. And that experience has told us that the effort it takes to build safe C code is beyond the discipline of most, if not all, development teams.
- pjmlp 7y ago
  Additionally, as proven by the latest JetBrains survey, the journeyman C developer doesn't care about those tools.

klez 7y ago

The difference is that if the bug is in the runtime you have to fix one place and everyone downstream gets that. If you solve one such bug in curl, you solved it just in curl. EDIT: I thought about it a bit more and realized it cuts both ways. If you have an RCE in a standard library a lot of programs get an RCE for free while it's not patched. So yeah, a bit of a mixed bag.

ppseafield 7y ago
There's also the difference that, in a GC'd language, you don't have both the language authors and the language users both competing to put these kinds of bugs in their software. :)
- tomatocracy 7y ago
  True, but when you want to interface between code written in two different GC'd languages then you can get similar problems if you're not careful. As the number and use of these various next generation languages proliferates, I suspect we might start to see more of that kind of thing appearing over time.
oconnor663 7y ago
I posted a bit more beside this comment, but I think the difference isn't so much updates or code review but rather the design intention of the language. A language like Java or Python or Rust is designed for every operation to produce some defined behavior, and you can't generally trigger RCE unless you call some function like `unsafePerilousDangerZone(heinousRawPtr)`. Those design defaults bubbles up through libraries written in those languages, so that when you use other people's code and make a mistake, the result is either a crash or an unfortunate-but-at-least-well-defined logic bug. The opposite is true in C and C++, and that bubbles up through the libraries in those languages too.
CaptainMarvel 7y ago
[[Off-Topic - Sorry!]] Hi Klez, I determined this to be the only way to get in touch regarding a previous discussion we had on Blendle [0] as I can no longer reply on that thread. This was back in 2017 so they may have fixed their issues. Alexander Klöpping <alexander.klopping@blendle.com> emailed me, I'll grant it was a generic welcome email, asking for feedback. I took the opportunity to email back informing him of the problems with using my email address [1]. I don't recall the problem now, but it seems they accepted my email address but then later rejected it during the sign-up process (as I clearly received an email correctly...). I no longer have their response, but from memory, it was a different customer service person, and they rejected the idea that they had any problem AND/OR explicitly said they weren't going to make any changes. Oh, and they sent that response to the email that I explicitly said wouldn't work (it automatically gets sent to the trash to be deleted which is also why I don't have it any more). Their rejection of fixing their service is what made me decide to put Blendle in the trash category. [0]: https://news.ycombinator.com/item?id=20138213 https://news.ycombinator.com/item?id=20138213 [1]: My email, sent from X+Y@gmail.com Dear Alexander Klöpping, When I first heard about Blendle I was excited at the concept of being able to read high-quality journalism from multiple different sources through one - ad-free - platform and one reasonably-priced payment system, and so I signed up for the beta. I successfully started the process of joining Blendle by unlocking and selecting some preferences. However, I have been unable to proceed past entering my email address, X+Y@gmail.com. I should make it clear that the email address X@gmail.com cannot be used. Could you please assist me and help me get started with Blendle? Best, [redacted]
- klez 7y ago
  Hey, thanks for replying to that question :) I guess I should give some way to contact me in my profile for cases like this.

oconnor663 7y ago

> When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. The runtime (whichever one that is) is safe because its behavior is defined by design for all inputs. Yes there could be a bug, but the design is that all inputs should be defined, and doing something for any given input isn't rocket science. Out of bounds array indexes either panic/throw or return empty lists. That can lead to crashes and logic errors, sure, or maybe DOS attacks, but it cannot lead to undefined behavior or remote code execution. That's a world of difference. C and C++ by design expose heaps of undefined behavior to the caller. The tools for detecting UB are imperfect and don't work if the relevant inputs never show up in test cases. Even when veteran C coders develop the techniques and habits that let them write correct C, mistakes tend to show up at the integration points between libraries written by different people with different techniques and habits (https://youtu.be/HgtRAbE1nBM?t=2344 https://youtu.be/HgtRAbE1nBM?t=2344).

Groxx 7y ago

That's kinda like claiming "a single implementation that everyone uses is no more secure/stable than a million independent implementations", which is fairly ridiculous. It's not (just) "pushing the problem further under the carpet", it's centralizing risk and attention and fixes, which does work out quite well in practice.

AgentME 7y ago

>all I see is someone pushing the problem further under the carpet, into the runtime. How often are there bugs in language runtimes that cause vulnerabilities in programs that are exploitable by users putting in different data into an otherwise secure program? (I'm not talking about the case where the runtime has a sandbox that breaks when the user loads bad code into it; this is a use-case C/C++ don't even try to address so that would be comparing different things. I'm talking about cases where someone is running a program that communicates over the network and the program's own code is written correctly, but a problem in the runtime makes it so the program is vulnerable to remote code execution.) The main example I can think of like that was Shellshock, which was horrible, but I would never have held up Bash as an example of a safe language. Bash has always been on my short list next to C and C++ of languages to avoid because of how easy and common it is to make mistakes that are practically unnoticeable in review. >On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language. Junior developers can write a buggy mess in any language. C/C++ are practically the only popular languages where a junior developer can accidentally write a backdoor in average-looking code that doesn't use any APIs. I can tolerate some bugs in my software sometimes, but exploitable bugs are an entirely different thing to me.

jcranmer 7y ago

Let's say there's a trillion lines of code written in C, and a million lines of code written in the runtime for a safe language where the trust is being pushed into. That means you can throw a million times the resources at finding and fixing the bugs in the runtime. While the payoff ratio is going to be far less than linear, you're looking at the C code being buggier and problematic by 100×. Actually, the situation for C is even worse than that makes it appear. C, both the language itself and the infrastructure ecosystem around it, actively fight you when you try to build and use tools to proactively find problems. The only tooling that tends to be effective in practice is built on dynamic analysis, which means that you can only be in confident in the safety of your code as you can be in your testing regime--and there are very few, if any, codebases that have a strong enough testing regime. We, as an industry, have almost 50 years of coding in C. And that experience has told us that the effort it takes to build safe C code is beyond the discipline of most, if not all, development teams.

pjmlp 7y ago
Additionally, as proven by the latest JetBrains survey, the journeyman C developer doesn't care about those tools.