Re: [commit: ghc] master: add note about compilation safety to safe haskell docs (b78b6b3)

On Mon, Nov 12, 2012 at 02:19:38PM +0000, Simon Marlow wrote:
> On 10/11/2012 02:47, Ian Lynagh wrote:
> >On Fri, Nov 09, 2012 at 05:46:05PM -0800, David Terei wrote:
> >>On 9 November 2012 17:36, Ian Lynagh <[email protected]> wrote:
> >>>On Fri, Nov 09, 2012 at 04:34:20PM -0800, David Terei wrote:
> >>>>
> >>>>+  Safe Haskell, however, <emphasis>does not offer</emphasis> compilation
> >>>>+  safety.
> >>>
> >>>Is this a bug? A few lines lower down the docs say that "Compiling and
> >>>executing untrusted code" is one of the two use cases for Safe Haskell.
> >>
> >>What matters is, does this problem make Safe Haskell unusable. I'd
> >>argue no,
> >
> >FWIW, I'd say yes, as it doesn't allow the use cases I can think of (OK,
> >it does work for lambdabot/tryhaskell, but only because they only allow
> >toy expressions to be evaluated).
> 
> What's wrong with using a sandbox?

According to the docs, "Compiling and executing untrusted code" is one
of the two use cases Safe Haskell has been designed for. If "use a
sandbox" is an acceptable part of the answer, then why did we need Safe
Haskell for that use case at all? Isn't the entire use case solved by
"use a sandbox"?

To answer the question, sandboxes are effort to set up and make/keep
secure. It would be great if we could just "cabal install a-pure-package"
and use that package, confident that it cannot do anything nasty, without
needing to manually audit the code.

> Note that even if we tackled the
> problem of safe compilation in GHC, that still doesn't help if
> you're using Cabal, which would also need some explicit support for
> safe compilation (e.g. to disable the use of Setup.hs, hsc2hs, and
> who knows what else).

Agreed, but there's no motivation for anyone to make the Cabal changes
unless there's a way to make the compiler safe.


Thanks
Ian