Re: [go-nuts] Generics security discussion.
On Wed, Jan 13, 2021 at 6:38 AM Kevin Chadwick wrote: > > On 1/13/21 2:09 PM, Axel Wagner wrote: > > Let me repeat my question: Do you have any concrete reason to assume there > > is a > > negative security impact of generics? Feel free to bring that up. > > Otherwise, I > > don't see a reason to talk about it in the design doc. > > I don't and I don't mean to make demands of other peoples time. Though I'm > sure > security has been carefully considered and might be fresh in peoples minds. It > might be worth formalising it, in any case. I am sure some members of the rust > community will do so likely inaccurately, if/when Generics are released. > > Despite seeing horrible to read code, again on Reddit today. The blog asked > for > us to consider voting. I'm inclined to upvote if the security of Go code is > expected to increase, otherwise I would likely down vote for readability > concerns. As Axel has suggested, in general code written using type parameters is more secure, because more types can be checked at compile time. In the current Go language, any type assertion that does not use the comma-ok form can (in principle) panic at run time. If similar code is written using type parameters rather than interface types, those type errors will be detected at compile time. Therefore, on balance, code that uses type parameters is more secure. There are of course many other possible security issues that are made neither better nor worse by type parameters. Ian -- 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/CAOyqgcVpG5uEABFAZbhhDsF3n6z7sFizza6yex2cxztF6umxDw%40mail.gmail.com.
Re: [go-nuts] Generics security discussion.
On Wed, Jan 13, 2021 at 3:38 PM Kevin Chadwick wrote: > I don't and I don't mean to make demands of other peoples time. Though I'm > sure > security has been carefully considered and might be fresh in peoples minds. I don't think it has, because I don't think it needs to be. There is no reason to think that there are any security implications. > I am sure some members of the rust community will do so likely > inaccurately, if/when Generics are released. > Okay. It seems like a complete waste of their time, but as far as I'm concerned, that's no ones problem but their own. Despite seeing horrible to read code, again on Reddit today. The blog asked > for > us to consider voting. I'm inclined to upvote if the security of Go code is > expected to increase, otherwise I would likely down vote for readability > concerns. > Feel free to make a judgement in any case. My personal projection is that security will mostly be unaffected (I don't know of many security issues in the past that were related to Go type safety or lack thereof), if it *is* affected, the effect will be positive and that type-safety will increase. > > -- > 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/bd5281c2-f231-f84c-cf42-f84372b30bb7%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/CAEkBMfFjr49F-MPx0xnksfz%3DSRzAtbZFtmR9p0XW_N5rJyjJFA%40mail.gmail.com.
Re: [go-nuts] Generics security discussion.
I covered the DoS. There are multitude of ways to create DoS even in “correct” code, panics are just one example. Memory corruption is a different class of security bug because it allows arbitrary code execution. > On Jan 13, 2021, at 8:20 AM, Kevin Chadwick wrote: > > On 1/13/21 2:06 PM, Robert Engels wrote: >> A panic is not a security issue. Memory corruption/stack overflow is. In Go >> the latter is accomplished through CGo and unsafe pointers/operations. >> > > It isn't as clear cut as that. Panics can be security issues and memory > corruption/stack overflows can also result in DOS and not necessarily be > exploitable. > > Granted panics should be handled and are largely akin to logic errors, except > when the compiler would have prevented that failure before release. Logic > errors > are the biggest cause of security issues in Go > > Personally. I would restart a panicked process or process group, without > exception and treat it more severely, if it happens. > > -- > 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/f48d42d3-f3cc-a78a-6168-91522636a0d3%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/5CBDDAA3-3F0F-4137-A219-7378052D460D%40ix.netcom.com.
Re: [go-nuts] Generics security discussion.
On 1/13/21 2:09 PM, Axel Wagner wrote: > Let me repeat my question: Do you have any concrete reason to assume there is > a > negative security impact of generics? Feel free to bring that up. Otherwise, I > don't see a reason to talk about it in the design doc. I don't and I don't mean to make demands of other peoples time. Though I'm sure security has been carefully considered and might be fresh in peoples minds. It might be worth formalising it, in any case. I am sure some members of the rust community will do so likely inaccurately, if/when Generics are released. Despite seeing horrible to read code, again on Reddit today. The blog asked for us to consider voting. I'm inclined to upvote if the security of Go code is expected to increase, otherwise I would likely down vote for readability concerns. -- 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/bd5281c2-f231-f84c-cf42-f84372b30bb7%40gmail.com.
Re: [go-nuts] Generics security discussion.
On 1/13/21 2:06 PM, Robert Engels wrote: > A panic is not a security issue. Memory corruption/stack overflow is. In Go > the latter is accomplished through CGo and unsafe pointers/operations. > It isn't as clear cut as that. Panics can be security issues and memory corruption/stack overflows can also result in DOS and not necessarily be exploitable. Granted panics should be handled and are largely akin to logic errors, except when the compiler would have prevented that failure before release. Logic errors are the biggest cause of security issues in Go Personally. I would restart a panicked process or process group, without exception and treat it more severely, if it happens. -- 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/f48d42d3-f3cc-a78a-6168-91522636a0d3%40gmail.com.
Re: [go-nuts] Generics security discussion.
On Wed, Jan 13, 2021 at 2:59 PM Kevin Chadwick wrote:
> Clearly Go without interfaces, especially an empty interface is safer.
> Perhaps
> Generics reduce that risk via constraints etc.?
>
I understand why you might argue interfaces make the language less safe.
But generics are a mechanism with the express (and arguably only) purpose
of *adding* type-safety.
> Really. If you avoid interfaces and pointers. Is it even possible to
> panic...maybe with channels.
There's that, writing to a nil-map, accessing a slice out of bounds and
simply writing `panic("foo")`.
I don't understand this line of inquiry. Yes, a completely different
language, which removes most of the features from Go might be able to
provide more type-safety. So? Safety is not the be-all and end-all of
language features, there are languages which provide *far* more type-safety
than Go.
> I'm not trolling or anything. I just feel that a risk analysis section by
> those
> that understand all the details, might be useful to people, before
> deciding on a
> thumbs up or down?
>
Let me repeat my question: Do you have any concrete reason to assume there
is a negative security impact of generics? Feel free to bring that up.
Otherwise, I don't see a reason to talk about it in the design doc.
>
> --
> 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/5274cf02-a9a7-357d-e498-b979c1b02f15%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/CAEkBMfFahGx1qxLKXr%2BfPBzpUPGEEY0B-bpY6nPZnHB5Wqx6pQ%40mail.gmail.com.
Re: [go-nuts] Generics security discussion.
A panic is not a security issue. Memory corruption/stack overflow is. In Go the latter is accomplished through CGo and unsafe pointers/operations. Continuous panics can be considered a security issue as a DoS attack but IMO at least there are many ways to generate continuous errors that are similar (and are best mitigated through external controls/monitoring). > On Jan 13, 2021, at 7:59 AM, Kevin Chadwick wrote: > > On 1/13/21 11:17 AM, Axel Wagner wrote: >>Assuming generics like interfaces, potentially erode type safety. >> >> >> Can you elaborate? Because that statement seems exactly contrary to >> established >> wisdom. > > Clearly Go without interfaces, especially an empty interface is safer. Perhaps > Generics reduce that risk via constraints etc.? > >>How many security issues and/or production panics to date might have been >>avoided by avoiding interface use all together? >> >> >> I assume panics in production are sufficiently common > > Really. If you avoid interfaces and pointers. Is it even possible to > panic...maybe with channels. I don't use exceptions personally. Perhaps that > is > what you mean? > > I'm not trolling or anything. I just feel that a risk analysis section by > those > that understand all the details, might be useful to people, before deciding > on a > thumbs up or down? > > -- > 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/5274cf02-a9a7-357d-e498-b979c1b02f15%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/C5D91D76-A284-421E-AF91-CDCF2ABF211B%40ix.netcom.com.
Re: [go-nuts] Generics security discussion.
On 1/13/21 11:17 AM, Axel Wagner wrote: > Assuming generics like interfaces, potentially erode type safety. > > > Can you elaborate? Because that statement seems exactly contrary to > established > wisdom. Clearly Go without interfaces, especially an empty interface is safer. Perhaps Generics reduce that risk via constraints etc.? > How many security issues and/or production panics to date might have been > avoided by avoiding interface use all together? > > > I assume panics in production are sufficiently common Really. If you avoid interfaces and pointers. Is it even possible to panic...maybe with channels. I don't use exceptions personally. Perhaps that is what you mean? I'm not trolling or anything. I just feel that a risk analysis section by those that understand all the details, might be useful to people, before deciding on a thumbs up or down? -- 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/5274cf02-a9a7-357d-e498-b979c1b02f15%40gmail.com.
Re: [go-nuts] Generics security discussion.
On Wed, Jan 13, 2021 at 11:54 AM Kevin Chadwick wrote: > I appreciate that generics use will be optional. However I am concerned > that neither in the design draft nor the proposal issue, that the word > security nor safety has been used even once. "Safety" has been mentioned lots of times, in the form of "type-safety". "Security" hasn't - I assume that is because the only mention would be "we don't expect any security impact". I think claiming the opposite is sufficiently counter-intuitive, to put the burden of proof on you, to make an argument that there is some. > Assuming generics like interfaces, potentially erode type safety. Can you elaborate? Because that statement seems exactly contrary to established wisdom. Will generics increase the likelihood of security issues, aside from panics? > Can you give an example of a security issue that they might cause? Because I really can't imagine any. Again, if anything, I would expect fewer panics due to more type-safety, so at least fewer DoS attacks (though, to be clear, I think it is more likely they are completely neutral). How many security issues and/or production panics to date might have been > avoided by avoiding interface use all together? > I assume panics in production are sufficiently common that you could find some to point at and attribute them to a use of interfaces. Security issues are significantly less common. Maybe you can point to some? Preferably some with CVE numbers assigned. > > -- > 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/DEFAB41C-6AF9-49FE-955A-4ED730C57DDE%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/CAEkBMfGcrOn3%2B%2BC-Jc3fmL2Gx2uuYacQyr773Jb1HsXsxekytQ%40mail.gmail.com.
[go-nuts] Generics security discussion.
I appreciate that generics use will be optional. However I am concerned that neither in the design draft nor the proposal issue, that the word security nor safety has been used even once. Assuming generics like interfaces, potentially erode type safety. Will generics increase the likelihood of security issues, aside from panics? Will it make package choice more important as a result? Now for the one where I may need to duck afterwards. How many security issues and/or production panics to date might have been avoided by avoiding interface use all together? -- 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/DEFAB41C-6AF9-49FE-955A-4ED730C57DDE%40gmail.com.
