<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I've been considering using it for safety-critical software to prevent things similar to the event-stream fiasco from happening,<div class="">where someone took over maintenance of an npm library that was a transitive dependency of a bitcoin wallet </div><div class="">application and injected malware that stole the users' secret keys and money.</div><div class=""><a href="https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident" class="">https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident</a><br class=""><div><br class=""></div><div>Would Safe Haskell be effective against those kinds of attacks? It should allow using a large amount of transitive dependencies,</div><div>without having to manually verify the safety of anything but the core trusted packages, right?</div><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Apr 2021, at 03:02, Richard Eisenberg <rae@richarde.dev> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi café,<div class=""><br class=""></div><div class="">Do you use Safe Haskell? Do you know someone who does? If you do, which of Safe Haskell's guarantees do you rely on?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/9562" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/9562</a>.) 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: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/19590" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/19590</a>. 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Richard</div></div>_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe<br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></div></body></html>