About the gosec G115 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 panic at all.

There are consequences: CWE-190. Please note CWE-190 is Common Weakness that affects a lot of language, and that is documented since 2006-07-19.

• 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 1.60.2

Many people disabled gosec G115, because of the false positives and noise it was bringing to the CI. They were so numerous false-positives, they couldn't be fixed with a //nolint:gosec // disable G115 directive.

The problem is now (almost) fixed with golangci-lint 1.61.0 (that ships gosec v2.21.2, there are still a few remaining false-positive issues that need to be addressed, but they are less frequent.

Unfortunately, during that 2 weeks delay, many people chose to disable the G115 checker, you can see it easily on GitHub

Maybe, they would enable them back now.