Generics security discussion.

[Kevin Chadwick]

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?

[Axel Wagner]

On Wed, Jan 13, 2021 at 11:54 AM Kevin Chadwick <m8il...@gmail.com> 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...@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.

[Kevin Chadwick]

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?

[Robert Engels]

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 <m8il...@gmail.com> wrote:

> --
> 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...@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.

[Axel Wagner]

On Wed, Jan 13, 2021 at 2:59 PM Kevin Chadwick <m8il...@gmail.com> 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...@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.

[Kevin Chadwick]

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.

[Kevin Chadwick]

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.

[Robert Engels]

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 <m8il...@gmail.com> wrote:

> --
> 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...@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.

[Axel Wagner]

On Wed, Jan 13, 2021 at 3:38 PM Kevin Chadwick <m8il...@gmail.com> 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...@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.

[Ian Lance Taylor]

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