Re: [Haskell-cafe] Safe Haskell?

I've been considering using it for safety-critical software to prevent things similar to the event-stream fiasco from happening, where someone took over maintenance of an npm library that was a transitive dependency of a bitcoin wallet application and injected malware that stole the users' secret keys and money. https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-inci... Would Safe Haskell be effective against those kinds of attacks? It should allow using a large amount of transitive dependencies, without having to manually verify the safety of anything but the core trusted packages, right?

On 17 Apr 2021, at 03:02, Richard Eisenberg wrote:

Hi café,

Do you use Safe Haskell? Do you know someone who does? If you do, which of Safe Haskell's guarantees do you rely on?

Here, a user of Safe Haskell is someone who relies on any guarantees that Safe Haskell provides, not someone who makes sure to have the right pragmas, etc., in your library so that users can import it Safely.

Context: Safe Haskell is not lightweight to support within GHC and the ecosystem. Despite being a formidable research project with a (in my opinion) quite worthwhile goal, it's unclear which of Safe Haskell's purported guarantees are actually guaranteed by GHC. (The lack of unsafeCoerce is not actually guaranteed: https://gitlab.haskell.org/ghc/ghc/-/issues/9562 https://gitlab.haskell.org/ghc/ghc/-/issues/9562.) Recent design questions about what should be Safe and what shouldn't be (somehow cannot find the discussion after a few minutes of searching; perhaps fill this in) have been answered only by stabs in the dark. The status quo is causing pain: https://gitlab.haskell.org/ghc/ghc/-/issues/19590 https://gitlab.haskell.org/ghc/ghc/-/issues/19590. There are hundreds (maybe thousands) of lines of delicate logic within GHC to support Safe Haskell. These parts of GHC have to be read, understood, and maintained by people with limited time.

I thus wonder about deprecating and eventually removing Safe Haskell. I don't have a concrete plan for how to do this yet, but I'm confident we could come up with a migration strategy.

The set of people who would win by removing Safe Haskell is easy enough to discover. But this email is intended to discover who would be harmed by doing so. If you know, speak up. Otherwise, I expect I will write up a GHC proposal to remove the feature.

Thanks, Richard _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.