On Wed, Jan 20, 2021 at 12:47 PM Kevin Chadwick <m8il1i...@gmail.com> wrote:
> I know Go is far from plagued by these issues and I certainly wouldn't > want to > trade Gos simplicity away. However, there seems to be a playing down of > null > pointers and type safety issue potential. > I don't understand what you are trying to say or achieve. But, to be clear: 1. Yes, Go does intentionally not attempt to build a type-system which excludes as many bugs as possible statically. 2. Yes, there is a possibility that Go software has security bugs that could (or would) have been caught by a more powerful type-system. Language design is a trade-off and there is no such thing as a perfect type-system. Go has decided that it doesn't want to occupy the "most type-safety possible" spot in the language design space. I don't think it is true that anyone is "downplaying" any type-safety issues of nil-pointers and the like. Is this not a type safety issue? > > "https://www.cvedetails.com/cve/CVE-2019-14809/"; > I'm not entirely certain, but I don't think so. AIUI the main issue you are attributing to a type-safety problem is that (*net.URL).Port() used to return non-numeric ports on malformed URLs. But that's a library issue, not an issue with the language type-system - `int` is a supported type and it would have prevented this. A Haskell library that returns a String could have exactly the same issue, even though the Haskell type system is significantly more powerful than Go's. This also hints at the core of *why* Go doesn't attempt to occupy the "most type-safety possible" spot in the design space. The marginal benefits of type-safety tend towards zero, while the marginal cost doesn't (I would even claim that it *increases*). At some point, you end up in a situation where your program is totally valid, including all the invariants you encoded into your types - but you still have bugs, because you encoded the wrong invariants. This is what happened here - the library said `Port` is a `string` and the type-system diligently (and correctly) checked that that's the case. And the reason the library said that isn't, that they were unable to say it's an integer. > > and obviously null dereferences that can cause critical service failures > to need > investigating urgently. > > "https://access.redhat.com/security/cve/cve-2020-29652"; > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/ddf94844-7cf3-2366-691f-7b915e6dce1f%40gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEQDo6AzFy7ggKYpM%2B_CD7TMg3GfTz1KjbtE6FuXn1T_w%40mail.gmail.com.
