Re: [Haskell-cafe] Safe Haskell?

On 2021-04-21 9:36 a.m., Sven Panne wrote:

Am Mi., 21. Apr. 2021 um 14:55 Uhr schrieb Mario mailto:blamario@rogers.com>:

[...] No general-purpose language (open field) is. You want to design from scratch, starting with a secure core language (high ground). You can use Haskell as an inspiration; Marlowe and probably some other blockchain languages do.

That's not totally correct: You can use anything you like when you have a sandbox while executing it. This is even much more safe than relying on a language (which can have conceptual and/or implementation bugs) alone. The attack surface of any non-trivial language, its implementation and its runtime is just too big for anything serious. Sandboxes are complex, too, but less so, and you implement them once and you can use them for many things. Having said that, my personal view is that Safe Haskell has almost no valid use case anymore, given the various sandboxing technologies available today. But that's just my 2c...

I'm disappointed you haven't continued the encampment analogy. That's especially unforgivable because it actually does provide an insight in this case. Allow me to analogize your argument: Instead of worrying about digging ditches and raising ramparts, why don't we just march into this friendly fort nearby, surrounded by a moat with a drawbridge? Let's just frolic inside. To which the age-old answer is: why not both? Sure, use the ready fortifications if you can find them. But that doesn't mean you can just drop your guard, because enemy could infiltrate any outer defense. Even assuming the fortifications are impenetrable, you'll have to open your gates and lower the drawbridge occasionally. So you still want to keep patrols, guards, inner security, etc. Defense in depth. Analogy over, no sandbox will protect you from attacks like SQL injections or application-layer denial-of-service attacks. A type system designed for the purpose can protect you from both.