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 <m8il1i...@gmail.com> 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.
