Deprecating Safe Haskell, or heavily investing in it?
iavor.diatchki at gmail.com
Wed Dec 28 00:13:28 UTC 2022
I disagree that Safe Haskell is a failed experiment, and I think with a
little work could be a very valuable tool for auditing Haskell source code.
The main change I think we should make is to completely remove the source
code annotations, and instead expose an external mechanism (e.g. some sort
of file) for specifying which potentially unsafe modules one trusts and
which modules should be safe under those assumptions. Then GHC can do the
checking and inference just like now, and people can make their own safety
configurations depending on the threat model.
On Tue, Dec 27, 2022, 17:08 Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Tue, Dec 27, 2022 at 09:39:22PM +0100, Hécate wrote:
> > I came across the nsjail system from Google a little while after posting
> > this thread: https://github.com/google/nsjail/#overview
> Yes, this is the sort of thing that one can begin to trust, provided
> that the exposed capabalities are managed only by inclusion, all system
> calls, filesystem namespaces, network namespaces, ... that are not
> explicitly allowed are denied.
> > Perhaps we could get the most value for our buck if we externalise the
> > solution to work with OS-level mechanisms? What do you think of that?
> > Something based upon eBPF would certainly incur less modifications to
> > the RTS?
> Indeed, it would be simpler to leverage existing virtualisation and/or
> containerisation technologies, than build a new microkernel within the
> RTS. Consequently, I guess I am saying that "Safe Haskell" was an
> interesting research project, but may be a practical dead-end.
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs