[pull] master from golang:master#43
Merged
Merged
Conversation
tlsmlkem=0 and tlssecpmlkem=0 were never meant to forcibly disable PQ KEMs, they were only meant to restore the Go 1.24 and Go 1.26 defaults when Config.CurvePreferences is nil. I noticed this while struggling to add a non-default key exchange. While at it, make our behavior on unimplemented Config.CurvePreferences entries more consistent by ignoring them regardless of role. Udpates #69985 Updates #71206 Change-Id: I7d977282153b1d95fdb549efa92353e86a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777220 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
We now use SetGlobalRandom in recorded tests. It was already partially ineffective: ML-KEM encapsulation, used as part of X25519MLKEM768, doesn't take a source of randomness, and instead always uses the global random source. Fixes #79367 Change-Id: I1cc07ebec21bee32ece685efde188c0d6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/765926 Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com>
We were using mlkem.NewDecapsulationKey on a random slice to support Config.Rand, but Encapsulate was already bypassing Config.Rand anyway. Config.Rand is deprecated anyway in favor of cryptotest.SetDefaultRandom, so switch to mlkem.GenerateKey which has better FIPS 140-3 compliance. Updates #79367 Change-Id: I62a5099bd69a1ee2941d5ae1c9c2bf4b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777320 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com>
Fixes #78543 Change-Id: I26a70a64665c75e5116b83f73a75093f6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777221 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
This test is failing on the noopt builder, where disabling inlining prevents the compiler from avoiding the allocation. Fixes #79502 Change-Id: I795284fa42c50174720c8b6ca08cf75e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/779960 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
Change-Id: I574b2443ea3695264379da28425acf716a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/725040 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
Updates #75316 Change-Id: I2efa3e485653f5b403d92e5d99959e356a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777380 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Updates #75316 Change-Id: I6eb8482505a83b8b63edcb7d443e227a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777381 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Updates #75316 Change-Id: Iedd2a6746d0ebd6a7b7147f34cb7435b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777382 TryBot-Bypass: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
Updates #75316 Change-Id: I43e7311777fb79b9486a05c8e8d3a42e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777383 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes #75316 Change-Id: I241af97bf6a05e94f40a9f62393ed4fe6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777384 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
Change-Id: Iaaa0bc449ce24c81f1052b89152c3b5a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777880 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This can include e.g. an error that mentiones that ML-DSA is not available due to the FIPS 140-3 module version. Change-Id: I6f505d9baff80fee23edf6f8e995dd846a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/777881 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
It's an API misuse and it's unreachable from other standard library packages, but since it produces/accepts trivially forged signatures, reject it explicitly. Change-Id: If7a56d18d6ec445a4d2620a71d85ab7d6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/765640 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com>
Unfortunately, SignASN1 doesn't take the hash function at all, but PrivateKey.Sign does, so we can check the hash length there. This is arguably a breaking change, but the previous behavior is almost certain to be a bug. opts was allowed to be nil, so continue to allow that. Change-Id: I75a11ab3f9df9de4234b1fc913f26ab06a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/765641 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Similar to the prior largeexponent.go work this adds a new testing only private key type & associated API surface for performing RSA OAEP encryption and decryption. This is necessary to support ACVP KTS-IFC testing with random exponents, since we can't constrain the ACVP server selected exponent to the range supported by the production APIs. We take the hit of duplicating some code to this test only package instead of increasing the complexity of the production code only to support this narrow usage. Change-Id: I3e34385e808da4cd40dd81e8553e0a92a6c294fe Reviewed-on: https://go-review.googlesource.com/c/go/+/769760 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com>
This is a semantic conflict between CL 779920 and CL 779960. Change-Id: I0a6e153200d8c0ef0c1cad05e52b42176a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/780060 TryBot-Bypass: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Starting with CL 779300, we return an error if fields with a `string` tag do not have a supported type. Most field validation occurs in makeStructFields. makeStructFields runs in a per-type sync.Once, with errors reported during each Marshal/Unmarshal call before any marshaling or unmarshaling begins. The string validation semantics depend on the StringifyWithLegacySemantics option, so the full validation cannot occur inside the sync.Once. Instead each Marshal/Unmarshal call must loop over every field to perform validation. We must use a second loop over the fields rather than performing validation inline inside the main marshal loop to match the other field validation semantic of reporting errors before marshaling begins. The loop isn't very expensive, but it does double the number of times we need to loop at each struct field. Package benchmarks did not show any statistically significant regressions on specific benchmarks (all regressions I saw disappear when running just that benchmark with more iterations). Regardless, BenchmarkUnmarshal/Struct/ManySmall spends ~2% of CPU time on this loop. Most structs won't have any fields with a string tag, so add a simple hint for when at least one field has the tag, and skip the validation loop otherwise. For #79065. Change-Id: I6f8b7d8c120c43e68b32dd1b19107d266a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/779940 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Updates #76244 Change-Id: Id5dac150a179246d3b73dfdab6653b362cbbded9 Reviewed-on: https://go-review.googlesource.com/c/go/+/777620 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org> Commit-Queue: Paul Murphy <paumurph@redhat.com> Auto-Submit: Paul Murphy <paumurph@redhat.com>
Follow-up on CL 752220. Change-Id: I848f9e721b0a209c70903bfb23a38f3d716c65a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/779921 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
The testJSONFilter.process was implicitly depending on the exact internal buffer size of the json.Decoder, which happened to be large enough in v1 for most lines that cmd/dist cared about. However, the re-implementation of v1 using encoding/json/v2 changes the implicit buffer size used, which results in some trailing bytes accidentally being discarded. The correct use of json.Decoder.Buffered requires also consulting the input io.Reader for additional trailing data. Fixes #79498 Change-Id: If4bdac12b638d78e0870808f2285fb1731b0fae6 Reviewed-on: https://go-review.googlesource.com/c/go/+/779980 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This ensures that input with unexpected characters like control characters will not be interpreted in unintended ways should they ever be printed or logged. Change-Id: I9ee18b44d8ca067886dca065e5aae9266a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/780041 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <husin@google.com>
Change-Id: Ieec72362bacf1956a2bd5e0b2eb8dad88e624bd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/745980 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
With the introduction of checklinkname, using linkname to reference a symbol from a different symbol is checked, and is permitted only when there is a push linkname. One exception is that linkname reference to an assembly symbol is always permitted, for now. This CL addresses this exception, and let checklinkname handle assembly symbols as well. The rule is similar to Go functions: linkname access is permitted if there is a push linkname annotation. One trickiness is that the assembly function is defined in assembly, whereas the annotation is in Go. They are different objects. To connect the two, we apply the annotation to the ABI wrapper, and let the linker to check the ABI wrapper symbol. A further complication is that on non-regABI platforms there is no ABI wrapper. In this case, we just allow the access for now. As most popular platforms are register ABI platforms, this shouldn't leave too big a hole. To allow one package pushes assembly functions to another, like, package a defines an assembly symbol b.F, it is permitted to reference directly from the target package (b in the example) based on the name. This change also makes it handle linkname references to ABI wrappers more strict. Previously it was always permitted. Now we treat the ABI wrapper the same as the underlying symbol. With this, we can migrate runtime.newcoro to linknamestd and remove it from the blocklist, and the coro_var and coro_asm test cases in cmd/link.TestCheckLinkname still pass. Change-Id: I6c03467d3eaaa536663e52ce289e3c1c23079aa6 Reviewed-on: https://go-review.googlesource.com/c/go/+/761481 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The native allocator seems faster for small things. Only start accessing the pool if we need something large. Currently "large" is more than 4 words. It seems a reasonable threshold, although I didn't do much experimentation to pick a number. Fixes #73999 1.24.2 to tip: goos: darwin goarch: arm64 pkg: github.com/dustin/go-humanize cpu: Apple M2 Ultra │ base │ pre │ │ sec/op │ sec/op vs base │ ParseBigBytes-24 625.0n ± 1% 665.8n ± 0% +6.53% (p=0.000 n=10) 1.24.2 to tip+this CL: goos: darwin goarch: arm64 pkg: github.com/dustin/go-humanize cpu: Apple M2 Ultra │ base │ post │ │ sec/op │ sec/op vs base │ ParseBigBytes-24 625.0n ± 1% 626.8n ± 0% ~ (p=0.470 n=10) Change-Id: Ic071e6d82d4aa4a0d3a6ec6e026f513c83cb0b37 Reviewed-on: https://go-review.googlesource.com/c/go/+/679475 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Fixes #78999 Change-Id: I9fba1fd771f06fc57de1ecb70d9f9cb8bc8078fe Reviewed-on: https://go-review.googlesource.com/c/go/+/771640 Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is meant to help evaluate CL 778981 For #79286 Change-Id: I361672582b16cce7746b659727d851106a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/779602 TryBot-Bypass: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Change-Id: I43f805d88553f858866fe82178b3dea22fe74a43 Reviewed-on: https://go-review.googlesource.com/c/go/+/779622 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> Auto-Submit: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Type constraint satisfaction is interface satisfaction. If a type does not satisfy a regular interface, it should also not satisfy the same interface as a type constraint. Otherwise, if the type satisfies the type constraint, one can use that to construct a (dynamic) interface value with a type that doesn't actually satisfy the interface. The go:nointerface directive tells the compiler that the method does not satisfy an interface. Therefore it should also not satisfy a type constraint. Fixes #74626. Change-Id: I7c64c76044a665755e4e74035085daff42447f9e Reviewed-on: https://go-review.googlesource.com/c/go/+/772620 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
…ssible Object resolution during parsing has always been problematic because there is incomplete type information, and the mechanism has beeen deprecated several years ago. Because of backward-compatibility, the mechanism - which was always enabled originally - must be explicitly disabled via the SkipObjectResolution mode. Almost none of the code in the std library requires it. Pass the SkipObjectResolution mode to parser.ParseFile where possible. This eliminates a typically unnecessary phase and may speed up the ParseFile call. Change-Id: Id74a4e8ca0cee781bc90b7d585f332a5220843b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/779982 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
For #79286 Change-Id: I0c201e1b68416a8adccc9aae5308657a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/773941 TryBot-Bypass: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
We check earlier that it's zero before entering the fast path. For #79286 Change-Id: I1f5d9d6c04bcf3a30e550423d1a47c236a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/780080 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )