aboutsummaryrefslogtreecommitdiff
path: root/src/internal/godebugs/table.go
AgeCommit message (Collapse)Author
2025-07-08cmd/go: disable support for multiple vcs in one moduleRoland Shoemaker
Removes the somewhat redundant vcs.FromDir, "allowNesting" argument, which was always enabled, and disallow multiple VCS metadata folders being present in a single directory. This makes VCS injection attacks much more difficult. Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior. Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue. Fixes #74380 Fixes CVE-2025-4674 Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789 Reviewed-on: https://go-review.googlesource.com/c/go/+/686515 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Commit-Queue: Carlos Amedee <carlos@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-05-21crypto/x509: use truncated SHA-256 for SubjectKeyIdFilippo Valsorda
Fixes #71746 Change-Id: I6a6a46568b092933d8ac2039df99ee9f0edf6e56 Reviewed-on: https://go-review.googlesource.com/c/go/+/674477 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21crypto/tls: disable SHA-1 signature algorithms in TLS 1.2Filippo Valsorda
This implements RFC 9155 by removing support for SHA-1 algorithms: - we don't advertise them in ClientHello and CertificateRequest (where supportedSignatureAlgorithms is used directly) - we don't select them in our ServerKeyExchange and CertificateVerify (where supportedSignatureAlgorithms filters signatureSchemesForCertificate) - we reject them in the peer's ServerKeyExchange and CertificateVerify (where we check against the algorithms we advertised in ClientHello and CertificateRequest) Fixes #72883 Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818 Reviewed-on: https://go-review.googlesource.com/c/go/+/658216 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-21internal/godebug,crypto/fips140: make fips140 setting immutableFilippo Valsorda
Updates #70123 Co-authored-by: qmuntal <quimmuntal@gmail.com> Change-Id: I6a6a4656fd23ecd82428cccbd7c48692287fc75a Reviewed-on: https://go-review.googlesource.com/c/go/+/657116 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
2025-05-21runtime: use cgroup CPU limit to set GOMAXPROCSMichael Pratt
This CL adds two related features enabled by default via compatibility GODEBUGs containermaxprocs and updatemaxprocs. On Linux, containermaxprocs makes the Go runtime consider cgroup CPU bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup limit is lower than the number of logical CPUs available, then the cgroup limit takes precedence. On all OSes, updatemaxprocs makes the Go runtime periodically recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has changed. If GOMAXPROCS is set manually, this update does not occur. This is intended primarily to detect changes to cgroup limits, but it applies on all OSes because the CPU affinity mask can change as well. The runtime only considers the limit in the leaf cgroup (the one that actually contains the process), caching the CPU limit file descriptor(s), which are periodically reread for updates. This is a small departure from the original proposed design. It will not consider limits of parent cgroups (which may be lower than the leaf), and it will not detection cgroup migration after process start. We can consider changing this in the future, but the simpler approach is less invasive; less risk to packages that have some awareness of runtime internals. e.g., if the runtime periodically opens new files during execution, file descriptor leak detection is difficult to implement in a stable way. For #73193. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98 Reviewed-on: https://go-review.googlesource.com/c/go/+/670497 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-18internal/godebugs: fix changed version for winsymlink and winreadlinkvolume ↵Jordan Liggitt
to 1.23 https://go.dev/doc/godebug#go-123 documents changes to winsymlink and winreadlinkvolume in Go 1.23. This fixes the registered "changed" minor version to Go 1.23, so that defaults when building a Go 1.22 module are correct. Fixes #72935 Change-Id: I5d5bf31ca04f9e95208fb0fdaad2232f9db653ff Reviewed-on: https://go-review.googlesource.com/c/go/+/659035 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2025-03-11cmd/go: allow symlinks of non-directory files in embedMichael Matloob
We previously disallowed all non-regular files being embedded. This CL relaxes the restriction a little: if the GODEBUG embedfollowsymlinks=1 is set, we allow the leaf files being embedded (not the directories containing them) to be symlinks. The files pointed to by the symlinks must still be regular files. This will be used when a Bazel build action executing the Go command is running in a symlink-based sandbox. It's not something we want to enable in general for now, so it's behind a GODEBUG. Fixes #59924 Change-Id: I895be14c12de55b7d1b663d81bdda1df37d54804 Reviewed-on: https://go-review.googlesource.com/c/go/+/643215 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2025-03-10internal/godebugs: add decoratemappings as an opaque godebug settingMichael Pratt
This adds a new godebug to control whether the runtime applies the anonymous memory mapping annotations added in https://go.dev/cl/646095. It is enabled by default. This has several effects: * The feature is only enabled by default when the main go.mod has go >= 1.25. * This feature can be disabled with GODEBUG=decoratemappings=0, or the equivalents in go.mod or package main. See https://go.dev/doc/godebug. * As an opaque setting, this option will not appear in runtime/metrics. * This setting is non-atomic, so it cannot be changed after startup. I am not 100% sure about my decision for the last two points. I've made this an opaque setting because it affects every memory mapping the runtime performs. Thus every mapping would report "non-default behavior", which doesn't seem useful. This setting could trivially be atomic and allow changes at run time, but those changes would only affect future mappings. That seems confusing and not helpful. On the other hand, going back to annotate or unannotate every previous mapping when the setting changes is unwarranted complexity. For #71546. Change-Id: I6a6a636c5ad551d76691cba2a6f668d5cff0e352 Reviewed-on: https://go-review.googlesource.com/c/go/+/655895 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2025-02-14internal/godebugs: add fips140 as an opaque godebug settingIan Lance Taylor
This permits using "godebug fips140=on" in go.mod and using "//go:debug fips140=on" in the main package. Change code references to the godebug setting to remove the # which is no longer required. For #71666 Change-Id: I3a60ecc55b03848dadd6d431eb43137b6df6568b Reviewed-on: https://go-review.googlesource.com/c/go/+/649495 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2024-11-30crypto/x509: keep RSA CRT values in ParsePKCS1PrivateKeyFilippo Valsorda
Turns out that recomputing them (and qInv in particular) in constant time is expensive, so let's not throw them away when they are available. They are much faster to check, so we now do that on precompute. Also, thanks to the opaque crypto/internal/fips140/rsa.PrivateKey type, we now have some assurance that the values we use are always ones we checked. Recovers most of the performance loss since CL 630516 in the happy path. Also, since now we always use the CRT, if necessary by running a throwaway Precompute, which is now cheap if PrecomputedValues is filled out, we effectively fixed the JSON round-trip slowdown (#59695). goos: darwin goarch: arm64 pkg: crypto/rsa cpu: Apple M2 │ 3b42687c56 │ f017604bc6-dirty │ │ sec/op │ sec/op vs base │ ParsePKCS8PrivateKey/2048-8 26.76µ ± 1% 65.99µ ± 1% +146.64% (p=0.002 n=6) Fixes #59695 Updates #69799 For #69536 Change-Id: I507f8c5a32e69ab28990a3bf78959836b9b08cc9 Reviewed-on: https://go-review.googlesource.com/c/go/+/632478 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-11-22crypto/tls: implement X25519MLKEM768Filippo Valsorda
This makes three related changes that work particularly well together and would require significant extra work to do separately: it replaces X25519Kyber768Draft00 with X25519MLKEM768, it makes CurvePreferences ordering crypto/tls-selected, and applies a preference to PQ key exchange methods over key shares (to mitigate downgrades). TestHandshakeServerUnsupportedKeyShare was removed because we are not rejecting unsupported key shares anymore (nor do we select them, and rejecting them actively is a MAY). It would have been nice to keep the test to check we still continue successfully, but testClientHelloFailure is broken in the face of any server-side behavior which requires writing any other messages back to the client, or reading them. Updates #69985 Fixes #69393 Change-Id: I58de76f5b8742a9bd4543fd7907c48e038507b19 Reviewed-on: https://go-review.googlesource.com/c/go/+/630775 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-22crypto/x509: switch default policy field to PoliciesRoland Shoemaker
Switch from Certificate.PolicyIdentifiers to Certificate.Policies when marshalling. Fixes #67620 Change-Id: Ib627135a569f53d344b4ee2f892ba139506ce0d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/629855 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org>
2024-11-22crypto/rsa: refuse to generate and/or use keys smaller than 1024 bitsFilippo Valsorda
Fixes #68762 Change-Id: Id89c770571d7cc27c6cf7932139ec3424383a7ef Reviewed-on: https://go-review.googlesource.com/c/go/+/629938 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-20crypto/x509: remove x509sha1 GODEBUGRoland Shoemaker
Fixes #41682 Change-Id: I37760f2186e75ec7df9674db25ae466cf453d66d Reviewed-on: https://go-review.googlesource.com/c/go/+/629676 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-11-19crypto/subtle: add DIT closureRoland Shoemaker
Add a new function, WithDataIndependentTiming, which takes a function as an argument, and encloses it with calls to set/unset the DIT PSTATE bit on Arm64. Since DIT is OS thread-local, for the duration of the execution of WithDataIndependentTiming, we lock the goroutine to the OS thread, using LockOSThread. For long running operations, this is likely to not be performant, but we expect this to be tightly scoped around cryptographic operations that have bounded execution times. If locking to the OS thread turns out to be too slow, another option is to add a bit to the g state indicating if a goroutine has DIT enabled, and then have the scheduler enable/disable DIT when scheduling a g. Additionally, we add a new GODEBUG, dataindependenttiming, which allows setting DIT for an entire program. Running a program with dataindependenttiming=1 enables DIT for the program during initialization. In an ideal world PSTATE.DIT would be inherited from the parent thread, so we'd only need to set it in the main thread and then all subsequent threads would inherit the value. While this does happen in the Linux kernel [0], it is not the case for darwin [1]. Rather than add complex logic to only set it on darwin for each new thread, we just unconditionally set it in mstart1 and cgocallbackg1 regardless of the OS. DIT will already impose some overhead, and the cost of setting the bit is only ~two instructions (CALL, MSR), so it should be cheap enough. Fixes #66450 Updates #49702 [0] https://github.com/torvalds/linux/blob/e8bdb3c8be08c9a3edc0a373c0aa8729355a0705/arch/arm64/kernel/process.c#L373 [1] https://github.com/apple-oss-distributions/xnu/blob/8d741a5de7ff4191bf97d57b9f54c2f6d4a15585/osfmk/arm64/status.c#L1666 Change-Id: I78eda691ff9254b0415f2b54770e5850a0179749 Reviewed-on: https://go-review.googlesource.com/c/go/+/598336 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19cmd/go: re-enable build JSON from go test -json, now with GODEBUGAustin Clements
This re-enables the behavior of CL 536399 (by effectively reverting CL 628955), so now go test -json again includes build output and failures as JSON rather than text. However, since this behavior is clearly enough to trip up some build systems, this CL includes a GODEBUG=gotestjsonbuildtext that can be set to 1 to revert to the old behavior. Fixes #70402. Updates #62067. Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_13,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Change-Id: I84e778cd844783dacfc83433e391b5ccb5925127 Reviewed-on: https://go-review.googlesource.com/c/go/+/629335 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Austin Clements <austin@google.com>
2024-10-28Revert "crypto/rand: add randcrash=0 GODEBUG"Filippo Valsorda
A GODEBUG is actually a security risk here: most programs will start to ignore errors from Read because they can't happen (which is the intended behavior), but then if a program is run with GODEBUG=randcrash=0 it will use a partial buffer in case an error occurs, which may be catastrophic. Note that the proposal was accepted without the GODEBUG, which was only added later. This (partially) reverts CL 608435. I kept the tests. Updates #66821 Change-Id: I3fd20f9cae0d34115133fe935f0cfc7a741a2662 Reviewed-on: https://go-review.googlesource.com/c/go/+/622115 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2024-10-07crypto/rand: add randcrash=0 GODEBUGFilippo Valsorda
For #66821 Change-Id: I525c308d6d6243a2bc805e819dcf40b67e52ade5 Reviewed-on: https://go-review.googlesource.com/c/go/+/608435 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-09-03net: enable multipath TCP by default for listenersAperence
A previous change [1] was introduced to enable MPTCP by default for both the clients and servers, based on the discussions [2] in golang#56539, where MPTCP would be an opt-in for a release or two, and then would become an opt-out. This change was not accepted at the time because the support for a few socket options was missing [3]. Now that this support has been added [4] and backported to stable versions not to block MPTCP deployment with Go, it sounds like a good time to reconsider the use of MPTCP by default. Instead of enabling MPTCP on both ends by default, as a first step, it seems safer to change the default behaviour only for the server side (Listeners). On the server side, the impact is minimal: when clients don't request to use MPTCP, server applications will create "plain" TCP sockets within the kernel when connections are accepted, making the performance impact minimal. This should also ease experiments where MPTCP is enabled by default on the client side (Dialer). The changes in this patch consist of a duplication of the mptcpStatus enumeration to have both a mptcpStatusDial and a mptcpStatusListen, where MPTCP is enabled by default in mptcpStatusListen, but disabled by default in mptcpStatusDial. It is still possible to turn MPTCP support on and off by using GODEBUG=multipathtcp=1. [1] https://go-review.googlesource.com/c/go/+/563575 [2] https://go.dev/issue/56539#issuecomment-1309294637 [3] https://github.com/multipath-tcp/mptcp_net-next/issues/383 [4] https://github.com/torvalds/linux/commit/bd11dc4fb969ec148e50cd87f88a78246dbc4d0b [5] https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default Updates #56539 Change-Id: I1ca0d6aaf74d3bda5468af135e29cdb405d3fd00 GitHub-Last-Rev: 5f9f29bfc13ad4ea6bfd1e0fc95a91bd824f4048 GitHub-Pull-Request: golang/go#69016 Reviewed-on: https://go-review.googlesource.com/c/go/+/607715 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthieu Baerts <matttbe@kernel.org> Auto-Submit: Ian Lance Taylor <iant@google.com>
2024-08-19math/rand: make calls to Seed no-opPaschalis T
Makes calls to the global Seed a no-op. The GODEBUG=randseednop=0 setting can be used to revert this behavior. Fixes #67273 Change-Id: I79c1b2b23f3bc472fbd6190cb916a9d7583250f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/606055 Auto-Submit: Cherry Mui <cherryyz@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-06-21time: provide non-default metric for asynctimerchanRuss Cox
The original implementation could not support a non-default metric, but now that it is set during package time, we can. Do that. Change-Id: If7929b0afa5b0142d299718d9bd811c5a8d1cf93 Reviewed-on: https://go-review.googlesource.com/c/go/+/589058 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-06-20internal/godebugs: fix old value for httpservecontentkeepheadersDamien Neil
The pre-Go 1.23 behavior is httpservecontentkeepheaders=1. For #66343 Change-Id: If6f92853b38522f19a8908ff11ac49b12f3dc3e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/593775 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-06-18net/http: keep Content-Encoding in Error, add GODEBUG for ServeContentDamien Neil
This reverts the changes to Error from CL 571995, and adds a GODEBUG controlling the changes to ServeContent/ServeFile/ServeFS. The change to remove the Content-Encoding header when serving an error breaks middleware which sets Content-Encoding: gzip and wraps a ResponseWriter in one which compresses the response body. This middleware already breaks when ServeContent handles a Range request. Correct uses of ServeContent which serve pre-compressed content with a Content-Encoding: gzip header break if we don't remove that header when serving errors. Therefore, we keep the change to ServeContent/ ServeFile/ServeFS, but we add the ability to disable the new behavior by setting GODEBUG=httpservecontentkeepheaders=1. We revert the change to Error, because users who don't want to include a Content-Encoding header in errors can simply remove the header themselves, or not add it in the first place. Fixes #66343 Change-Id: Ic19a24b73624a5ac1a258ed7a8fe7d9bf86c6a38 Reviewed-on: https://go-review.googlesource.com/c/go/+/593157 Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-06-18Revert "crypto/x509: reject serial numbers longer than 20 octets"Roland Shoemaker
This reverts commit 8524931a2cdc6a57afdf6f4b3375cb261c2557da. Reason for revert: It turns out, basically no one in private PKIs can get this right. It causes way too much breakage, and every other impl also ignores it, so we'll continue to be in good company. Change-Id: I2da808b411ec12f72112c49079faf9f68ae465c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/589615 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-06-12net: add GODEBUG=netedns0=0 to disable sending EDNS0 headerIan Lance Taylor
It reportedly breaks the DNS server on some modems. For #6464 For #21160 For #44135 For #51127 For #51153 Fixes #67925 Change-Id: I54a11906159f00246d08a54cc8be7327e9ebfd2c Reviewed-on: https://go-review.googlesource.com/c/go/+/591995 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-05-22crypto/tls: populate Leaf in X509KeyPairRoland Shoemaker
Fixes #67065 Change-Id: I189e194de8aa94523eb64e1dd294a70cb81cbdf6 Reviewed-on: https://go-review.googlesource.com/c/go/+/585856 Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2024-05-22crypto/tls: disable 3-DES by defaultFilippo Valsorda
Fixes #66214 Change-Id: Iba8006a17fc7cd33c7485ab1a1ef8f56531c0ed1 Reviewed-on: https://go-review.googlesource.com/c/go/+/587295 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2024-05-22crypto/x509: reject serial numbers longer than 20 octetsRoland Shoemaker
Updates #65085 Change-Id: I8e5fb6c77c54f07247b30afea9fe8c548bf6d0be Reviewed-on: https://go-review.googlesource.com/c/go/+/562975 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2024-05-22crypto/x509: reject negative serial numbersRoland Shoemaker
There is only one trusted certificate I could find in the web pki which has a negative serial number. Removing this exception seems reasonable. Updates #65085 Change-Id: I55435b3d75479dcb41d523383e4ff7894a1496ad Reviewed-on: https://go-review.googlesource.com/c/go/+/562343 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-05-22crypto/tls: implement X25519Kyber768Draft00Filippo Valsorda
Forced the testConfig CurvePreferences to exclude X25519Kyber768Draft00 to avoid bloating the transcripts, but I manually tested it and the tests all update and pass successfully, causing 7436 insertions(+), 3251 deletions(-). Fixes #67061 Change-Id: If6f13bca561835777ab0889a490487b7c2366c3c Reviewed-on: https://go-review.googlesource.com/c/go/+/586656 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-04-18go/types: track gotypesalias non-default behaviorRobert Griesemer
Fixes #66216. Change-Id: I04d7389e5712b35db078844ce424e10f5b96156c Reviewed-on: https://go-review.googlesource.com/c/go/+/579936 Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2024-04-17Revert "go/types, types2: track gotypesalias non-default behavior"Lasse Folger
This reverts commit c51f6c62576ab3088a981b9cef90e413ac99e333. Reason for revert: This breaks toolchain bootstrapping in Google. Root cause investigation is pending. Error message is: ``` <unknown line number>: internal compiler error: panic: godebug: Value of name not listed in godebugs.All: gotypesalias ``` Change-Id: Ie3dff566a29b3b0846ebc8fe0a371c656a043a4c Reviewed-on: https://go-review.googlesource.com/c/go/+/579575 Reviewed-by: Chressie Himpel <chressie@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Lasse Folger <lassefolger@google.com>
2024-04-16go/types, types2: track gotypesalias non-default behaviorRobert Griesemer
Fixes #66216. Change-Id: I2750a744d0dcf636a00d388299e1f2f993e5ac26 Reviewed-on: https://go-review.googlesource.com/c/go/+/572575 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2024-04-15go/types: flip the default value of GODEBUG=gotypesalias=1Alan Donovan
This CL changes the interpretation of the unset value of gotypesalias to equal "1". The actual deletion of all the transitional logic will happen in a follow-up. Note that the compiler still interprets unset as "0". More work appears to be required within the compiler before it is safe to flip its default. Change-Id: I854ab1fd856c7c361a757676b0670e2f23402816 Reviewed-on: https://go-review.googlesource.com/c/go/+/577715 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> Commit-Queue: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-03-14time: avoid stale receives after Timer/Ticker Stop/Reset returnRuss Cox
A proposal discussion in mid-2020 on #37196 decided to change time.Timer and time.Ticker so that their Stop and Reset methods guarantee that no old value (corresponding to the previous configuration of the Timer or Ticker) will be received after the method returns. The trivial way to do this is to make the Timer/Ticker channels unbuffered, create a goroutine per Timer/Ticker feeding the channel, and then coordinate with that goroutine during Stop/Reset. Since Stop/Reset coordinate with the goroutine and the channel is unbuffered, there is no possibility of a stale value being sent after Stop/Reset returns. Of course, we do not want an extra goroutine per Timer/Ticker, but that's still a good semantic model: behave like the channels are unbuffered and fed by a coordinating goroutine. The actual implementation is more effort but behaves like the model. Specifically, the timer channel has a 1-element buffer like it always has, but len(t.C) and cap(t.C) are special-cased to return 0 anyway, so user code cannot see what's in the buffer except with a receive. Stop/Reset lock out any stale sends and then clear any pending send from the buffer. Some programs will change behavior. For example: package main import "time" func main() { t := time.NewTimer(2 * time.Second) time.Sleep(3 * time.Second) if t.Reset(2*time.Second) != false { panic("expected timer to have fired") } <-t.C <-t.C } This program (from #11513) sleeps 3s after setting a 2s timer, resets the timer, and expects Reset to return false: the Reset is too late and the send has already occurred. It then expects to receive two values: the one from before the Reset, and the one from after the Reset. With an unbuffered timer channel, it should be clear that no value can be sent during the time.Sleep, so the time.Reset returns true, indicating that the Reset stopped the timer from going off. Then there is only one value to receive from t.C: the one from after the Reset. In 2015, I used the above example as an argument against this change. Note that a correct version of the program would be: func main() { t := time.NewTimer(2 * time.Second) time.Sleep(3 * time.Second) if !t.Reset(2*time.Second) { <-t.C } <-t.C } This works with either semantics, by heeding t.Reset's result. The change should not affect correct programs. However, one way that the change would be visible is when programs use len(t.C) (instead of a non-blocking receive) to poll whether the timer has triggered already. We might legitimately worry about breaking such programs. In 2020, discussing #37196, Bryan Mills and I surveyed programs using len on timer channels. These are exceedingly rare to start with; nearly all the uses are buggy; and all the buggy programs would be fixed by the new semantics. The details are at [1]. To further reduce the impact of this change, this CL adds a temporary GODEBUG setting, which we didn't know about yet in 2015 and 2020. Specifically, asynctimerchan=1 disables the change and is the default for main programs in modules that use a Go version before 1.23. We hope to be able to retire this setting after the minimum 2-year window. Setting asynctimerchan=1 also disables the garbage collection change from CL 568341, although users shouldn't need to know that since it is not a semantically visible change (unless we have bugs!). As an undocumented bonus that we do not officially support, asynctimerchan=2 disables the channel buffer change but keeps the garbage collection change. This may help while we are shaking out bugs in either of them. Fixes #37196. [1] https://github.com/golang/go/issues/37196#issuecomment-641698749 Change-Id: I8925d3fb2b86b2ae87fd2acd055011cbf7bd5916 Reviewed-on: https://go-review.googlesource.com/c/go/+/568341 Reviewed-by: Austin Clements <austin@google.com> Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-03-13time: garbage collect unstopped Tickers and TimersRuss Cox
From the beginning of Go, the time package has had a gotcha: if you use a select on <-time.After(1*time.Minute), even if the select finishes immediately because some other case is ready, the underlying timer from time.After keeps running until the minute is over. This pins the timer in the timer heap, which keeps it from being garbage collected and in extreme cases also slows down timer operations. The lack of garbage collection is the more important problem. The docs for After warn against this scenario and suggest using NewTimer with a call to Stop after the select instead, purely to work around this garbage collection problem. Oddly, the docs for NewTimer and NewTicker do not mention this problem, but they have the same issue: they cannot be collected until either they are Stopped or, in the case of Timer, the timer expires. (Tickers repeat, so they never expire.) People have built up a shared knowledge that timers and tickers need to defer t.Stop even though the docs do not mention this (it is somewhat implied by the After docs). This CL fixes the garbage collection problem, so that a timer that is unreferenced can be GC'ed immediately, even if it is still running. The approach is to only insert the timer into the heap when some channel operation is blocked on it; the last channel operation to stop using the timer takes it back out of the heap. When a timer's channel is no longer referenced, there are no channel operations blocked on it, so it's not in the heap, so it can be GC'ed immediately. This CL adds an undocumented GODEBUG asynctimerchan=1 that will disable the change. The documentation happens in the CL 568341. Fixes #8898. Fixes #61542. Change-Id: Ieb303b6de1fb3527d3256135151a9e983f3c27e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/512355 Reviewed-by: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org>
2024-03-13os,internal/godebugs: add missing IncNonDefault callsqmuntal
Fixes #66215 Change-Id: Id7de15feabe08f66c048dc114c09494813c9febc Reviewed-on: https://go-review.googlesource.com/c/go/+/570695 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-03-09internal/godebugs: test for use of IncNonDefaultRuss Cox
A few recent godebugs are missing IncNonDefault uses. Test for that, so that people remember to do it. Filed bugs for the missing ones. For #66215. For #66216. For #66217. Change-Id: Ia3fd10fd108e1b003bb30a8bc2f83995c768fab6 Reviewed-on: https://go-review.googlesource.com/c/go/+/570275 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-03-04os: don't normalize volumes to drive letters in os.Readlinkqmuntal
This CL updates os.Readlink so it no longer tries to normalize volumes to drive letters, which was not always even possible. This behavior is controlled by the `winreadlinkvolume` setting. For Go 1.23, it defaults to `winreadlinkvolume=1`. Previous versions default to `winreadlinkvolume=0`. Fixes #63703. Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64 Change-Id: Icd6fabbc8f0b78e23a82eef8db89940e89e9222d Reviewed-on: https://go-review.googlesource.com/c/go/+/567735 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-03-04os: don't treat mount points as symbolic linksqmuntal
This CL changes the behavior of os.Lstat to stop setting the os.ModeSymlink type mode bit for mount points on Windows. As a result, filepath.EvalSymlinks no longer evaluates mount points, which was the cause of many inconsistencies and bugs. Additionally, os.Lstat starts setting the os.ModeIrregular type mode bit for all reparse tags on Windows, except for those that are explicitly supported by the os package, which, since this CL, doesn't include mount points. This helps to identify files that need special handling outside of the os package. This behavior is controlled by the `winsymlink` GODEBUG setting. For Go 1.23, it defaults to `winsymlink=1`. Previous versions default to `winsymlink=0`. Fixes #39786 Fixes #40176 Fixes #61893 Updates #63703 Updates #40180 Updates #63429 Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64 Change-Id: I2e7372ab8862f5062667d30db6958d972bce5407 Reviewed-on: https://go-review.googlesource.com/c/go/+/565136 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-02-23Revert "os: make FindProcess use pidfd on Linux"Michael Pratt
This reverts CL 542699. Reason for revert: Some applications assume FindProcess does not return errors. For #62654. Fixes #65866. Change-Id: Ic185a6253c8e508b08150b618c39a9905f6cdd60 Reviewed-on: https://go-review.googlesource.com/c/go/+/566476 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2024-02-21os: make FindProcess use pidfd on LinuxKir Kolyshkin
Amend FindProcess to use pidfdFind, and make it return ErrProcessDone if pidfdFind is used and the process is not found. Since this is a change in API, introduce GODEBUG osfinderr=0 setting to disable the feature. Change-Id: I724c6f622f0c99f21a70b864cf7cf2b8836869ee Reviewed-on: https://go-review.googlesource.com/c/go/+/542699 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2023-12-11crypto/x509: gate Policies marshaling with GODEBUGRoland Shoemaker
Use a GODEBUG to choose which certificate policy field to use. If x509usepolicies=1 is set, use the Policies field, otherwise use the PolicyIdentifiers field. Fixes #64248 Change-Id: I3f0b56102e0bac4ebe800497717c61c58ef3f092 Reviewed-on: https://go-review.googlesource.com/c/go/+/546916 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-11-21crypto/tls: disable ExportKeyingMaterial without EMSFilippo Valsorda
Fixes #43922 Change-Id: Idaad7daa6784807ae3a5e4d944e88e13d01fd0b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/544155 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2023-11-14crypto/tls: remove RSA KEX ciphers from the default listRoland Shoemaker
Removes the RSA KEX based ciphers from the default list. This can be reverted using the tlsrsakex GODEBUG. Fixes #63413 Change-Id: Id221be3eb2f6c24b91039d380313f0c87d339f98 Reviewed-on: https://go-review.googlesource.com/c/go/+/541517 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2023-11-14crypto/tls: change default minimum version to 1.2Roland Shoemaker
Updates the default from 1.0 -> 1.2 for servers, bringing it in line with clients. Add a GODEBUG setting, tls10server, which lets users revert this change. Fixes #62459 Change-Id: I2b82f85b1c2d527df1f9afefae4ab30a8f0ceb41 Reviewed-on: https://go-review.googlesource.com/c/go/+/541516 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2023-11-13go/types, types2: implement Alias proposal (export API)Robert Griesemer
This CL exports the previously unexported Alias type and corresponding functions and methods per issue #63223. Whether Alias types are used or not is controlled by the gotypesalias setting with the GODEBUG environment variable. Setting gotypesalias to "1" enables the Alias types: GODEBUG=gotypesalias=1 By default, gotypesalias is not set. Adjust test cases that enable/disable the use of Alias types to use -gotypesalias=1 or -gotypesalias=0 rather than -alias and -alias=false for consistency and to avoid confusion. For #63223. Change-Id: I51308cad3320981afac97dd8c6f6a416fdb0be55 Reviewed-on: https://go-review.googlesource.com/c/go/+/541737 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2023-10-02net/http: add GODEBUG setting for old ServeMux behaviorJonathan Amsterdam
Add the GODEBUG setting httpmuxgo121. When set to "1", ServeMux behaves exactly like it did in Go 1.21. Implemented by defining a new, unexported type, serveMux121, that uses the original code. Updates #61410. Change-Id: I0a9d0fe2a2286e442d680393e62895ab50683cea Reviewed-on: https://go-review.googlesource.com/c/go/+/530461 Run-TryBot: Jonathan Amsterdam <jba@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2023-09-12all: calculate the median uniformlyJes Cok
This is a follow up of CL 526496. Change-Id: I9f351951bf975e31befd36b9c951d195d2f8f9f7 GitHub-Last-Rev: 4307adafbffef7494d6f807b69df3e56328d6bf4 GitHub-Pull-Request: golang/go#62590 Reviewed-on: https://go-review.googlesource.com/c/go/+/527576 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-08-11net/http: disallow empty Content-Length headerMauri de Souza Meneguzzo
The Content-Length must be a valid numeric value, empty values should not be accepted. See: https://www.rfc-editor.org/rfc/rfc9110.html#name-content-length Fixes #61679 Change-Id: Icbcd933087fe5e50199b62ff34c58bf92a09d3d4 GitHub-Last-Rev: 932e46b55b54d5f2050453bcaa50e9476c8559fd GitHub-Pull-Request: golang/go#61865 Reviewed-on: https://go-review.googlesource.com/c/go/+/517336 Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 06:14:11 +0000