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 <i...@well-typed.com> 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 _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
