Hello,

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.

Iavor

On Tue, Dec 27, 2022, 17:08 Viktor Dukhovni <ietf-dane@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.

--
Viktor.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs