Check for panics initiated by network IO

[stv0g]

By @koraa in https://github.com/stv0g/go-rosenpass/issues/27#issuecomment-1604364074

Severerity: N/A – Have you made sure to exclude the possibility of errors inside processing triggered by network messages that could crash the application?

[stv0g]

In Go, panic() and recover() are built-in functions for managing errors and exceptional situations:

1. panic(): Used to cause a program to halt immediately when an unrecoverable error occurs. It initiates a panic and unwinds the stack, potentially leading to program termination.

2. recover(): Used with the defer statement to capture and handle panics. It allows a program to regain control and potentially handle a panic gracefully by preventing it from propagating up the call stack.

Example

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from:", r)
        }
    }()

    if somethingBad {
        panic("Something bad happened!")
    }
    // Rest of the program
}

The go-rosenpass code-base itself is currently not using the panic() built-in. To fully guarantee that the critical network code-paths (Server.handle()) can not panic, we also need evaluate if any of the called functions from imported packages could panic(). Ideally, we would use static code analysis to check this. However, I am currently not aware of any tool which could do this (inputs are very welcome here).

Server.handle() is currently only calling into the following packages:

• fmt
• math
• time
• encoding/binary
• crypto/rand
• golang.org/x/crypto/blake2b
• golang.org/x/crypto/chacha20poly1305
• golang.org/x/exp/slog
• github.com/stv0g/circl

I checked the code of these packages to identify any call sites of panic() and verified that they can not be reached by Server.handle().

However, it is hard to really guarantee this without any sort if automation and continuous checks. Furthermore manual evaluation of the panic() call sites is error prone.

Further improvements

• Automate checks in CI by using static code analysis.

• 78. This would also allow us to recover from any runtime errors (such as nil dereferencing) (see ).