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



This content originally appeared on DEV Community and was authored by Christophe Colombier

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


This content originally appeared on DEV Community and was authored by Christophe Colombier