A process for reporting security-sensitive issues

[Richard Eisenberg]

I agree with Adam. I've been a little worried about users relying on Safe Haskell, despite #9562. Advertising that Safe Haskell is just a "best effort" (for a rather high bar for "best") but not a guarantee would be nice.

Richard

On Sep 3, 2015, at 10:50 PM, Adam Gundry <adam at well-typed.com> wrote:

> On 03/09/15 08:22, Michael Smith wrote:
>> I feel there should be some process for reporting security-sensitive issues
>> in GHC -- for example, #9562 and #10826 in Trac. Perhaps something like the
>> SensitiveTicketsPlugin [3] could be used?
>> 
>> [1] https://ghc.haskell.org/trac/ghc/ticket/9562
>> [2] https://ghc.haskell.org/trac/ghc/ticket/10826
>> [3] https://trac-hacks.org/wiki/SensitiveTicketsPlugin
> 
> Thanks for raising this. While I see where you are coming from, I'm
> going to argue against it, because I think it creates a false impression
> of the security guarantees GHC provides. Such a process may give the
> impression that there are people directly tasked with handling such
> security bugs, which is not currently the case.
> 
> I think it is unreasonable for the security of a system to depend on GHC
> having no type soundness bugs, particularly since GHC is actively used
> for developing experimental type system features. #9562 has been open
> for a year and we don't have a good solution.
> 
> Relatedly, I think the Safe Haskell documentation should prominently
> warn about the existence of #9562 and the possibility of other type
> soundness bugs, like it does for compilation safety issues.
> 
> What do others think?
> 
> Adam
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs