6 ms·

This shows me some surprising information -- Haskell is susceptible to heartbleed-like problems like C! Of course, you can write your own safe wrapper which ch

This shows me some surprising information -- Haskell is susceptible to heartbleed-like problems like C! Of course, you can write your own safe wrapper which checks deference, but one could just as easily (in fact, I think more easily) write such a thing in C...

tluyben2 12y ago
Compile time checks are quite a big step up from runtime (assert) checks.
jacquesm 12y ago
The problem with 'silver bullets' is that they are relatively untested. Once you get mass deployments of Haskell in the hostile environment that is the web these days it will become apparent whether or not the safety argument is as strong in practice as it is in theory. That is assuming that it will see such mass deployment which is not a foregone conclusion. That does not mean that it isn't good there are people trying to give us safer languages, but there is something disconcerting about the ease with which presumably bullet-proof Haskell can be made to do unsafe things like referring to out-of-bounds data, even if the reason is 'performance'. The whole idea was (or at least, that's what I thought it was) that you can get there at reasonable speed without giving up the safety net. Like this you might as well go the whole hog and program in C after all... It's a bit like making a vault that has the front door hinges and the lock screwed on from the outside. Compare with like Linux on the desktop not having too many viruses and such. The viruses aren't there because nobody is motivated enough to write them given the small distribution footprint of the OS. The money isn't there for the virus writers. Not because Linux is somehow magically resistant to viruses (though it does a few things better than say Windows). The number of people trying to bust down the barriers is roughly proportional to the size of the deployments, and I suspect that Haskell when put to the test will eventually turn out to have it's own (different) class of problems that have nothing to do with the class of problems that plagues the C like languages. Just like interpreted languages have a unique set of problems and virtual machines have their own. Silver bullets are rare.
- SixSigma 12y ago
  Viruses are harder on Linux because running random binaries is not a common usage pattern. Linux is exploited via remote execution or by passing payload data to be processed by the user using known vulnerable programs. The latter is harder to pull off. Getting access to Linux systems is not usually a problem of Linux itself. It happens a lot more than you think.
  - MichaelGG 12y ago
    >running random binaries is not a common usage pattern. Nor is checking the source code to whatever module or tool you need to compile and run.
    - SixSigma 12y ago
      That's what package maintainers are for, it would be a highly targeted attack if any of the code I compiled managed to be compromised. I would be impressed at being so important.
- bkirwi 12y ago
  As a fellow relatively new to Haskell, I was surprised at all the unsafe constructs in the core. Almost everything you'd expect to find in C's standard library is exposed somewhere, with roughly the same level of safety. (Which is to say, almost none.) The main difference I find between the two is that I have never needed to reach for an unsafe construct in Haskell myself - including some networking / parsing code that lives at roughly the same level of the stack as you'd find the heartbleed bug. The 'unsafe' functionality I use is encapsulated in libraries which expose a safer, higher-level interface. (Which is roughly the situation in Ruby with C bindings or Rust / Go with `unsafe` blocks.) I do feel there's a significant difference between a language where you need to be more-or-less constantly vigilant and one where you can isolate the memory management to a small, well-vetted library, but it's true that the situation still isn't ideal. (I think Haskell's story is much better as you move up the stack, but that's another story...) But if you're interested in a stronger level of safety in Haskell, you may be interested in Safe Haskell[0] -- it disables many of the unsafe features (or requires uses of them to be explicitly 'trusted') and thus provides much stronger safety guarantees. [0] http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-...
hiker 12y ago
It shows that, if you need to, you can drop to direct memory access in Haskell. Also note the "unsafe" in the names of the functions. Of course, the majority of Haskell code uses algebraic data types and garbage collection.
catsagainst 12y ago
And you can even segfault it with unsafePerformIO! … Now go read rest of the post > Of course, you can write your own safe wrapper which checks deference You don't generally. unsafe* functions practically are only used in libraries where you really need C-level speed. The next level of abstraction is their public API.
- CJefferson 12y ago
  The openSSL programmers were terrible C programmers, who seemed to make an active effort to disable any safety feature C implementations provided if it could gain them the tiniest speed improvement. I have no double they would have called 'unsafe' functions everywhere in Haskell. Certainly Haskell does have advantages over C (better type system, garbage collection), but I feel this article does a bad job explaining them an introduces a sausage to fortune by talking about Heartbleed.
  - tinco 12y ago
    Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. I would not expect any unsafe calls in a crypto library. It would defeat almost the whole purpose of implementing a crypto library in Haskell. It would be like implementing a web application in Ruby, and then using static type annotations everywhere using some eDSL. BTW, I don't think this article is meant to argue the advantages of Haskell, it is meant to describe a solution to a problem in Haskell.
    - CJefferson 12y ago
      Now wandering further off-topic I realise! I think everyone who had ever looked at the code for OpenSSL (including myself) knew it was an unsafe time bomb waiting to go off, it's just no-one could be bothered to replace it, or do the basic complete re-engineer the BSD folks are now doing.
      - gcr 12y ago
IsTom 12y ago
Any language that has C FFI is susceptible to heartbleed-like problems.

tluyben2 12y ago

Compile time checks are quite a big step up from runtime (assert) checks.

jacquesm 12y ago

The problem with 'silver bullets' is that they are relatively untested. Once you get mass deployments of Haskell in the hostile environment that is the web these days it will become apparent whether or not the safety argument is as strong in practice as it is in theory. That is assuming that it will see such mass deployment which is not a foregone conclusion. That does not mean that it isn't good there are people trying to give us safer languages, but there is something disconcerting about the ease with which presumably bullet-proof Haskell can be made to do unsafe things like referring to out-of-bounds data, even if the reason is 'performance'. The whole idea was (or at least, that's what I thought it was) that you can get there at reasonable speed without giving up the safety net. Like this you might as well go the whole hog and program in C after all... It's a bit like making a vault that has the front door hinges and the lock screwed on from the outside. Compare with like Linux on the desktop not having too many viruses and such. The viruses aren't there because nobody is motivated enough to write them given the small distribution footprint of the OS. The money isn't there for the virus writers. Not because Linux is somehow magically resistant to viruses (though it does a few things better than say Windows). The number of people trying to bust down the barriers is roughly proportional to the size of the deployments, and I suspect that Haskell when put to the test will eventually turn out to have it's own (different) class of problems that have nothing to do with the class of problems that plagues the C like languages. Just like interpreted languages have a unique set of problems and virtual machines have their own. Silver bullets are rare.

SixSigma 12y ago
Viruses are harder on Linux because running random binaries is not a common usage pattern. Linux is exploited via remote execution or by passing payload data to be processed by the user using known vulnerable programs. The latter is harder to pull off. Getting access to Linux systems is not usually a problem of Linux itself. It happens a lot more than you think.
- MichaelGG 12y ago
  >running random binaries is not a common usage pattern. Nor is checking the source code to whatever module or tool you need to compile and run.
  - SixSigma 12y ago
    That's what package maintainers are for, it would be a highly targeted attack if any of the code I compiled managed to be compromised. I would be impressed at being so important.
bkirwi 12y ago
As a fellow relatively new to Haskell, I was surprised at all the unsafe constructs in the core. Almost everything you'd expect to find in C's standard library is exposed somewhere, with roughly the same level of safety. (Which is to say, almost none.) The main difference I find between the two is that I have never needed to reach for an unsafe construct in Haskell myself - including some networking / parsing code that lives at roughly the same level of the stack as you'd find the heartbleed bug. The 'unsafe' functionality I use is encapsulated in libraries which expose a safer, higher-level interface. (Which is roughly the situation in Ruby with C bindings or Rust / Go with `unsafe` blocks.) I do feel there's a significant difference between a language where you need to be more-or-less constantly vigilant and one where you can isolate the memory management to a small, well-vetted library, but it's true that the situation still isn't ideal. (I think Haskell's story is much better as you move up the stack, but that's another story...) But if you're interested in a stronger level of safety in Haskell, you may be interested in Safe Haskell[0] -- it disables many of the unsafe features (or requires uses of them to be explicitly 'trusted') and thus provides much stronger safety guarantees. [0] http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-...

hiker 12y ago

It shows that, if you need to, you can drop to direct memory access in Haskell. Also note the "unsafe" in the names of the functions. Of course, the majority of Haskell code uses algebraic data types and garbage collection.

catsagainst 12y ago

And you can even segfault it with unsafePerformIO! … Now go read rest of the post > Of course, you can write your own safe wrapper which checks deference You don't generally. unsafe* functions practically are only used in libraries where you really need C-level speed. The next level of abstraction is their public API.

CJefferson 12y ago
The openSSL programmers were terrible C programmers, who seemed to make an active effort to disable any safety feature C implementations provided if it could gain them the tiniest speed improvement. I have no double they would have called 'unsafe' functions everywhere in Haskell. Certainly Haskell does have advantages over C (better type system, garbage collection), but I feel this article does a bad job explaining them an introduces a sausage to fortune by talking about Heartbleed.
- tinco 12y ago
  Maybe I'm naieve, but I think perhaps the problems with OpenSSL had come to light a little bit sooner if all dangerous code had clearly been marked 'unsafe'. I would not expect any unsafe calls in a crypto library. It would defeat almost the whole purpose of implementing a crypto library in Haskell. It would be like implementing a web application in Ruby, and then using static type annotations everywhere using some eDSL. BTW, I don't think this article is meant to argue the advantages of Haskell, it is meant to describe a solution to a problem in Haskell.
  - CJefferson 12y ago
    Now wandering further off-topic I realise! I think everyone who had ever looked at the code for OpenSSL (including myself) knew it was an unsafe time bomb waiting to go off, it's just no-one could be bothered to replace it, or do the basic complete re-engineer the BSD folks are now doing.
    - gcr 12y ago

IsTom 12y ago

Any language that has C FFI is susceptible to heartbleed-like problems.