[Haskell-cafe] Safe Haskell?

[Andreas Källberg]

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-incident

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 <rae at richarde.dev> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210418/494e274c/attachment.html>