aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/cgo/main.go
diff options
context:
space:
mode:
authorRuss Cox <rsc@golang.org>2022-04-27 09:03:28 -0400
committerRuss Cox <rsc@golang.org>2022-04-29 14:23:17 +0000
commitfe006d641079e8943833573bd1275ef51eb7fb60 (patch)
tree3dbb788b864e749680f68ea0a658f0f6e33dfb20 /src/cmd/cgo/main.go
parentec7f5165ddc680efbac18dc15b4905844d9e8db9 (diff)
downloadgo-fe006d641079e8943833573bd1275ef51eb7fb60.tar.gz
go-fe006d641079e8943833573bd1275ef51eb7fb60.zip
[dev.boringcrypto] cmd/internal/notsha256: add new package
Package notsha256 implements the NOTSHA256 hash, defined as bitwise NOT of SHA-256. It will be used from the Go compiler toolchain where an arbitrary hash is needed and the code currently reaches for MD5, SHA1, or SHA256. The problem with all of those is that when we add GOEXPERIMENT=boringcrypto, the bootstrap process will not converge if the compiler itself depends on the boringcrypto cgo code. Using notsha256 avoids boringcrypto. It is possible that I don't fully understand the convergence problem and that there is a way to make the compiler converge when using cgo, but keeping cgo out of the compiler seems safest. It also makes clear that (except for the hack in codesign) the code using this package doesn't care which hash is used. For #51940. Change-Id: Ie7c661183eacf8413a9d2074c96cbb9361e125ef Reviewed-on: https://go-review.googlesource.com/c/go/+/402594 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
Diffstat (limited to 'src/cmd/cgo/main.go')
0 files changed, 0 insertions, 0 deletions
id='n237' href='#n237'>237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298