About the gosec G drama, or how I faced back integer conversion overflow in Go

Go is a strongly typed language, it avoids making mistakes.

I wrongly assumed Go was handling integer overflows, and reported an error.

Here is the perfect world where everything works as expected

a := int64(42)
b := uint8(a)
fmt.Println(b) // 42

So what does the following code

a = 255 + 1    // 255 is the higher value an uint8 can reach
b = uint8(a)
fmt.Println(b) // ?

a = -1
b = uint8(a)
fmt.Println(b) // ?

Here is the solution

Spoiler: it doesn't work as expected, or at least as we could expect.

So here Go is doing a silent conversion, of course it cannot store the value in the integer types provided, but there is no error at all.

There are consequences: CWE-190

• Imagine you access a resource by its identifier, but you need to convert from an integer type to another, you may allow to access to another resource.

Because of this, gosec a linter focused on improving the security in Go, provided a linter to detect the issue: the linter G115

The G115 linter idea was good.

But it was unfortunately merged with some false issues, that are now addressed, except a few ones.

The problem becomes massive after gosec v2.21.0 was merged into golangci-lint

Many people disabled gosec G115, because of the false positives and noise it was bringing to the CI

So now many people unfortunately disabled the G115 checker, you can see it easily on GitHub

The above is the detailed content of About the gosec G drama, or how I faced back integer conversion overflow in Go. For more information, please follow other related articles on the PHP Chinese website!