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-d...@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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
