[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Tomasz Zielonka]

On Tue, Dec 19, 2006 at 12:52:17PM +0100, Joachim Durchholz wrote:
> Tomasz Zielonka schrieb:
> >On Mon, Dec 18, 2006 at 12:14:36AM +0100, Joachim Durchholz wrote:
> >>Haskell might be prone to denial-of-service attacks. E.g. sending it 
> >>data that cause it to evaluate an infinite data structure.
> >
> >That would be a bug in the implementation of an algorithm, not an
> >inherent Haskell problem.
> 
> In the same way one could argue that running over the end of an array in 
> C is a bug in the implementation of an algorithm, not an inherent C problem.

But the C bug can cause vastly more unexpected things, and can often
be used by an attacker to run arbitrary code in your program.

> IOW it's the same kind of problem: a kind of bug that the language, by 
> its very nature, allows.

Trying to fully evaluate an infinite data structure will result in
looping or memory exhaustion, and you have that possibilities in almost
all languages.

> potential for driving Haskell programs into nontermination by feeding 
> them cleverly constructed inputs

But you agree that not all Haskell programs have this caveat? For
correct programs you would have to actually feed them an infinitely big
input to get nontermination.

Some propose a variant of Haskell built on a strongly normalising
calculus to reduce the risk of inadvertent nontermination.

> I'm not sure that this problem really exists. It's just a potential 
> problem that's difficult to diagnose. In other words, this kind of 
> problem won't get much notice until people start attacking Haskell code 
> in earnest.

I think it's a similar kind of problem as the possibility of making an
imperative program enter an infinite loop.

> >>Still, I'd want to have the results of a strictness analysis attached to 
> >>Haskell software.
> >
> >Why? In case the strictness analyzer was buggy?
> 
> I'd be perfectly happy if that analysis were just a note saying "run ghc 
> with such-and-these options and inspect the intermediate code for 
> function foo to see that the strictness analyzer determined it will 
> always terminate".

I think you are asking too much from the strictness analyzer.

Best regards
Tomasz