À propos du drame de Gosec G, ou de la façon dont j'ai fait face au débordement de conversion d'entiers dans Go

Go est un langage fortement typé, il évite de faire des erreurs.

J'ai supposé à tort que Go gérait les dépassements d'entiers et j'ai signalé une erreur.

Voici le monde parfait où tout fonctionne comme prévu

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

Alors que fait le code suivant

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) // ?

Voici la solution

Spoiler : cela ne fonctionne pas comme prévu, ou du moins comme on pouvait s'y attendre.

Donc, ici, Go effectue une conversion silencieuse, bien sûr, il ne peut pas stocker la valeur dans les types entiers fournis, mais il n'y a aucune erreur.

Il y a des conséquences : CWE-190

• Imaginez que vous accédez à une ressource par son identifiant, mais que vous devez convertir d'un type entier à un autre, vous pouvez autoriser l'accès à une autre ressource.

Pour cette raison, gosec un linter axé sur l'amélioration de la sécurité dans Go, a fourni un linter pour détecter le problème : le linter G115

L'idée du linter G115 était bonne.

Mais il a malheureusement été fusionné avec quelques faux problèmes, qui sont désormais résolus, à l'exception de quelques-uns.

Le problème devient massif après la fusion de gosec v2.21.0 dans golangci-lint

De nombreuses personnes ont désactivé le Gosec G115, à cause des faux positifs et du bruit qu'il apportait au CI

Alors maintenant, beaucoup de gens ont malheureusement désactivé le vérificateur G115, vous pouvez le voir facilement sur GitHub

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!