10 ms·

This comes around to me as something that just shouldn't have happened. CloudFlare are pretty big on Go, as far as I can tell (and I guess Lua for scripting ngi

This comes around to me as something that just shouldn't have happened. CloudFlare are pretty big on Go, as far as I can tell (and I guess Lua for scripting nginx). Why was this parsing package written in a non memory-safe language? Parsing is one of those "obvious" things easy to mess up; the likelihood of a custom, hand written parser being buggy is pretty high. If it's somehow understood that your library is likely to have bugs, why do it in C/C++, where bugs often lead to bleeding memory? In a shop that's already fluent in Go, where they have the institutional knowledge to do it safely? Sure performance is not going to be the same, but with some care it'll get pretty close. Sorry I hate to just be a coach commentator. Obviously hindsight is 20/20. Still I think there's a lesson here.

belovedeagle 10y ago
Memory safe languages aren't a panacea. There could just as easily have been a bug in the compiler or standard library with the same result.
- AYBABTME 10y ago
  Sure... but that probability is equally present in the non memory-safe language, so that doesn't change anything.
  - ndesaulniers 10y ago
    I've yet to learn a language where not handling exceptional cases properly did not result in a bug.
    - AYBABTME 10y ago
      The point is not the absence of bugs. In a memory safe language, usually a bug doesn't lead in leaking the content of freed memory.
hkjgkjy 10y ago
True. I don't understand why many of us programmers are not interested in tools that eliminate the possibility of errors? * Why do we use memoy-unsafe languages (except when Rust or GC is unusable)? * Why do we use type-unsafe languages, at all? * Why do we use state-unsafe (mutable) languages, at all? Of course there are exceptions to these - but they are few.
- ddebernardy 10y ago
  There aren't so many languages that are a) memory safe, b) type safe, and c) thread safe, that additionally offer d) a large enough pool of developers to recruit from.
  - bbcbasic 10y ago
    You don't need (d) but lest anyone realise it. Now get me a Java dev whose been sitting in a chair at a desk for 10k hours.
aleksei 10y ago
It is not the fault of the language if you use it wrong. CloudFlare is to blame here, nothing else. As for the reason why C, I'm pretty confident they knew what they were doing, and had considered other tools that did not meet all requirements.
- MrBuddyCasino 10y ago
  Security is a requirement. They must have been extremely confident indeed to write something like this in C, where a single mistake can make your program fail in catastrophic ways, with no help whatsoever from the compiler. If some code has bugs, did the author just "use the language wrong"? People make mistakes, and we can prevent some of them by using better tools.
- pmontra 10y ago
  Allow me an analogy. It's not the fault of a rope if you use it to cross between two skyscrapers and slip and fall to the ground. But if if you mind your life you use at least a safety cable to tie you to the rope, or use the lifts and cross at road level. There are still cars to watch for, but... C is simply too dangerous, even the best developer can slip without noticing. There are safer alternatives now, we should start using them at least for new projects.
- alkonaut 10y ago
  No, the language is bad if using it wrong can leak sensitive data. The choice of language is wrong if you pick such a language in a situation where mistakes can lead to safety or security problems. The first requirement is security.
  - megous 10y ago
    You can leak sensitive data with any language. C is not used for web development on the client side, yet people abuse security holes in web apps all the time.
    - alkonaut 10y ago
mook 10y ago
The blog post makes it seem like the problem was in an nginx module. Looking at the docs [1] it looks like that's a C API; as far as I know writing shared libraries in golang for a C caller isn't really a thing (because the runtime needs to exist). Rust might have better luck here (I _think_ there have been attempts to get rust code loaded by not-rust code), but I haven't kept track. [1] https://www.nginx.com/resources/wiki/extending/api/main/ https://www.nginx.com/resources/wiki/extending/api/main/
- MrBuddyCasino 10y ago
  Calling Rust from C is easy. Details: http://siciarz.net/24-days-of-rust-calling-rust-from-other-languages/ http://siciarz.net/24-days-of-rust-calling-rust-from-other-l...
  - duneroadrunner 10y ago
    And if you need a more expedient fix for existing C/C++ code, there's SaferCPlusPlus[1]. [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
ars 10y ago
This could easily happen in Go as well. All that would be needed is to reuse the buffer in between requests, and rely on the buffer length instead of clearing it. To make it safer you would need to deallocate and reallocate the buffer for each request, but that might be slow. Doing that would fix it for Go, or for C, it would be the same either way. So I'm not convinced that using Go would have helped here.
- duneroadrunner 10y ago
  It's a good point, but at least with Go the leak would be limited to the allocated buffer. This is probably a case where Rust or C++ might be more helpful. Presumably you wouldn't want to allocate a new (variable sized) buffer each time (particularly in a GC language), but you could create a new (bounds checked) slice[1] / array_view[2] / gsl::span / RandomAccessSection[3] each time. [1] https://doc.rust-lang.org/nightly/std/slice/ https://doc.rust-lang.org/nightly/std/slice/ [2] https://github.com/rhysd/array_view https://github.com/rhysd/array_view [3] https://github.com/duneroadrunner/SaferCPlusPlus#txscoperandomaccesssection-txscoperandomaccessconstsection-trandomaccesssection-trandomaccessconstsection https://github.com/duneroadrunner/SaferCPlusPlus#txscoperand...
- drvdevd 10y ago
  I agree. I keep seeing comments about C being the culprit, but in my mind, this is more of a policy issue regarding how any given language initializes and allocates memory. Sure, in this case, we may see a C-specific bug in play, but I think this sort of bug is more effectively mitigated by forcing buffers to be zero-filled upon allocation and/or deallocation, and perhaps system-wide at the OS level, rather than relying upon language features to cover it. So - I'm not explicitly defending C here - I just don't think a similar bug could never occur in a "memory safe" language as well.
- zzzcpan 10y ago
  "This could easily happen in Go as well." Not really true. Go operates on slices that panic on out-of-bounds accesses. So, for this to happen in Go you would have to reinvent slices and use a lot of manual C-style code to operate on them, which literally nobody does in Go, because it's too hard.

belovedeagle 10y ago

Memory safe languages aren't a panacea. There could just as easily have been a bug in the compiler or standard library with the same result.

AYBABTME 10y ago
Sure... but that probability is equally present in the non memory-safe language, so that doesn't change anything.
- ndesaulniers 10y ago
  I've yet to learn a language where not handling exceptional cases properly did not result in a bug.
  - AYBABTME 10y ago
    The point is not the absence of bugs. In a memory safe language, usually a bug doesn't lead in leaking the content of freed memory.

hkjgkjy 10y ago

True. I don't understand why many of us programmers are not interested in tools that eliminate the possibility of errors? * Why do we use memoy-unsafe languages (except when Rust or GC is unusable)? * Why do we use type-unsafe languages, at all? * Why do we use state-unsafe (mutable) languages, at all? Of course there are exceptions to these - but they are few.

ddebernardy 10y ago
There aren't so many languages that are a) memory safe, b) type safe, and c) thread safe, that additionally offer d) a large enough pool of developers to recruit from.
- bbcbasic 10y ago
  You don't need (d) but lest anyone realise it. Now get me a Java dev whose been sitting in a chair at a desk for 10k hours.

aleksei 10y ago

It is not the fault of the language if you use it wrong. CloudFlare is to blame here, nothing else. As for the reason why C, I'm pretty confident they knew what they were doing, and had considered other tools that did not meet all requirements.

MrBuddyCasino 10y ago
Security is a requirement. They must have been extremely confident indeed to write something like this in C, where a single mistake can make your program fail in catastrophic ways, with no help whatsoever from the compiler. If some code has bugs, did the author just "use the language wrong"? People make mistakes, and we can prevent some of them by using better tools.
pmontra 10y ago
Allow me an analogy. It's not the fault of a rope if you use it to cross between two skyscrapers and slip and fall to the ground. But if if you mind your life you use at least a safety cable to tie you to the rope, or use the lifts and cross at road level. There are still cars to watch for, but... C is simply too dangerous, even the best developer can slip without noticing. There are safer alternatives now, we should start using them at least for new projects.
alkonaut 10y ago
No, the language is bad if using it wrong can leak sensitive data. The choice of language is wrong if you pick such a language in a situation where mistakes can lead to safety or security problems. The first requirement is security.
- megous 10y ago
  You can leak sensitive data with any language. C is not used for web development on the client side, yet people abuse security holes in web apps all the time.
  - alkonaut 10y ago

mook 10y ago

The blog post makes it seem like the problem was in an nginx module. Looking at the docs [1] it looks like that's a C API; as far as I know writing shared libraries in golang for a C caller isn't really a thing (because the runtime needs to exist). Rust might have better luck here (I _think_ there have been attempts to get rust code loaded by not-rust code), but I haven't kept track. [1] https://www.nginx.com/resources/wiki/extending/api/main/ https://www.nginx.com/resources/wiki/extending/api/main/

MrBuddyCasino 10y ago
Calling Rust from C is easy. Details: http://siciarz.net/24-days-of-rust-calling-rust-from-other-languages/ http://siciarz.net/24-days-of-rust-calling-rust-from-other-l...
- duneroadrunner 10y ago
  And if you need a more expedient fix for existing C/C++ code, there's SaferCPlusPlus[1]. [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

ars 10y ago

This could easily happen in Go as well. All that would be needed is to reuse the buffer in between requests, and rely on the buffer length instead of clearing it. To make it safer you would need to deallocate and reallocate the buffer for each request, but that might be slow. Doing that would fix it for Go, or for C, it would be the same either way. So I'm not convinced that using Go would have helped here.

duneroadrunner 10y ago
It's a good point, but at least with Go the leak would be limited to the allocated buffer. This is probably a case where Rust or C++ might be more helpful. Presumably you wouldn't want to allocate a new (variable sized) buffer each time (particularly in a GC language), but you could create a new (bounds checked) slice[1] / array_view[2] / gsl::span / RandomAccessSection[3] each time. [1] https://doc.rust-lang.org/nightly/std/slice/ https://doc.rust-lang.org/nightly/std/slice/ [2] https://github.com/rhysd/array_view https://github.com/rhysd/array_view [3] https://github.com/duneroadrunner/SaferCPlusPlus#txscoperandomaccesssection-txscoperandomaccessconstsection-trandomaccesssection-trandomaccessconstsection https://github.com/duneroadrunner/SaferCPlusPlus#txscoperand...
drvdevd 10y ago
I agree. I keep seeing comments about C being the culprit, but in my mind, this is more of a policy issue regarding how any given language initializes and allocates memory. Sure, in this case, we may see a C-specific bug in play, but I think this sort of bug is more effectively mitigated by forcing buffers to be zero-filled upon allocation and/or deallocation, and perhaps system-wide at the OS level, rather than relying upon language features to cover it. So - I'm not explicitly defending C here - I just don't think a similar bug could never occur in a "memory safe" language as well.
zzzcpan 10y ago
"This could easily happen in Go as well." Not really true. Go operates on slices that panic on out-of-bounds accesses. So, for this to happen in Go you would have to reinvent slices and use a lot of manual C-style code to operate on them, which literally nobody does in Go, because it's too hard.