Fork of Go programming language with my patches. http://git.kilabit.info/go/atom?h=go1.20.9 2023-10-05T19:28:06Z 2023-10-05T19:28:06Z Gopher Robot gobot@golang.org 2023-10-05T18:32:36Z urn:sha1:68f9a6e2addc828246992e66e79c6a51a32d1d71 Change-Id: Ic4eedc3dc193c335784b5a86214ea2e655e631a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/533237 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Michael Pratt <mpratt@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> 2023-10-05T18:31:32Z Ian Lance Taylor iant@golang.org 2023-09-20T23:16:29Z urn:sha1:31d5b604ac0adb58aec4870ac1b974c08312fd49 For #23672 Updates #63211 Fixes #63213 Fixes CVE-2023-39323 Change-Id: I4586a69e1b2560036afec29d53e53cf25e6c7352 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2032884 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> (cherry picked from commit 9b19e751918dd218035811b1ef83a8c2693b864a) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2037629 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/533195 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Bypass: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com> 2023-09-21T22:22:16Z Cherry Mui cherryyz@google.com 2023-07-10T22:50:06Z urn:sha1:83dce45959669a3b090d6701605a7ba408a10587 ld-prime emits a deprecation warning for -bind_at_load. The flag is needed for plugins to not deadlock (#38824) when linking with older darwin linker. It is supposedly not needed with newer linker when chained fixups are used. For now, we always pass it, and suppress the warning. Updates #61229. For #62597. Change-Id: I4b8a6f864a460c40dc38adbb533f664f7fd5343c Reviewed-on: https://go-review.googlesource.com/c/go/+/508696 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> (cherry picked from commit 040dbf9c181a0e3ea9f7bd3ebe3f75acdc878aaf) Reviewed-on: https://go-review.googlesource.com/c/go/+/527798 2023-09-21T22:20:27Z Cherry Mui cherryyz@google.com 2023-09-12T19:42:29Z urn:sha1:08c544db98da4292edfc5da7ceca17808fd41168 [This is a (manual) backport of CL 527415 to Go 1.20.] Currently, linking a Go c-shared object with C code using Apple's new linker, it fails with % cc a.c go.so ld: segment '__DWARF' filesize exceeds vmsize in 'go.so' Apple's new linker has more checks for unmapped segments. It is very hard to make it accept a Mach-O shared object with an additional DWARF segment. We may want to stop combinding DWARF into the shared object (see also #62577). For now, disable DWARF by default in c-shared mode on darwin. Updates #61229. For #62597. Change-Id: I313349f71296d6d7025db28469593825ce9f1866 Reviewed-on: https://go-review.googlesource.com/c/go/+/527819 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> 2023-09-21T22:20:16Z Cherry Mui cherryyz@google.com 2023-09-12T19:40:09Z urn:sha1:071f03a8e59fc404a823e547fa566983c60f1f07 There are some bugs in Apple's new linker that probably will not be fixed when Xcode 15 is released (some time soon). We fix/work around them but it is too much to backport them all. Force old Apple linker to work around. Updates #61229. For #62597. Change-Id: Ia5941918e882b22b4dbc41c74764d19d413d0b56 Reviewed-on: https://go-review.googlesource.com/c/go/+/527818 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> 2023-09-06T15:31:47Z Gopher Robot gobot@golang.org 2023-09-06T14:25:34Z urn:sha1:d5b851804329aa547dafa278a0c35dd62298d651 Change-Id: Iac628daa970d01c5958839fcf668106e93bce8b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/526037 Reviewed-by: Joedian Reid <joedian@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> 2023-09-06T14:22:36Z Roland Shoemaker bracewell@google.com 2023-08-03T19:28:28Z urn:sha1:2070531d2f53df88e312edace6c8dfc9686ab2f5 The HTML specification has incredibly complex rules for how to handle "<!--", "<script", and "</script" when they appear within literals in the script context. Rather than attempting to apply these restrictions (which require a significantly more complex state machine) we apply the workaround suggested in section 4.12.1.3 of the HTML specification [1]. More precisely, when "<!--", "<script", and "</script" appear within literals (strings and regular expressions, ignoring comments since we already elide their content) we replace the "<" with "\x3C". This avoids the unintuitive behavior that using these tags within literals can cause, by simply preventing the rendered content from triggering it. This may break some correct usages of these tags, but on balance is more likely to prevent XSS attacks where users are unknowingly either closing or not closing the script blocks where they think they are. Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue. Fixes #62197 Fixes #62397 Fixes CVE-2023-39319 [1] https://html.spec.whatwg.org/#restrictions-for-contents-of-script-elements Change-Id: Iab57b0532694827e3eddf57a7497ba1fab1746dc Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976594 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2014621 TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/526099 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> 2023-09-06T14:22:29Z Roland Shoemaker bracewell@google.com 2023-08-03T19:24:13Z urn:sha1:023b542edf38e2a1f87fcefb9f75ff2f99401b4c Per Appendix B.1.1 of the ECMAScript specification, support HTML-like comments in script contexts. Also per section 12.5, support hashbang comments. This brings our parsing in-line with how browsers treat these comment types. Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue. Fixes #62196 Fixes #62395 Fixes CVE-2023-39318 Change-Id: Id512702c5de3ae46cf648e268cb10e1eb392a181 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976593 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2014620 Reviewed-on: https://go-review.googlesource.com/c/go/+/526098 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 2023-08-24T21:11:06Z David Chase drchase@google.com 2023-08-15T21:45:50Z urn:sha1:612da32fb5e9c1e9641cd55dc269518426057ea9 For aggregate-typed arguments passed to a call, expandCalls decomposed them into parts in the same block where the value was created. This is not necessarily the call block, and in the case where stores are involved, can change the memory leaving that block, and getting that right is problematic. Instead, do all the expanding in the same block as the call, which avoids the problems of (1) not being able to reorder loads/stores across a block boundary to conform to memory order and (2) (incorrectly, not) exposing the new memory to consumers in other blocks. Putting it all in the same block as the call allows reordering, and the call creates its own new memory (which is already dealt with correctly). Fixes #62056. Updates #61992. Change-Id: Icc7918f0d2dd3c480cc7f496cdcd78edeca7f297 Reviewed-on: https://go-review.googlesource.com/c/go/+/519276 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit e72ecc6a6becab9ca895c0108047db4723394296) Reviewed-on: https://go-review.googlesource.com/c/go/+/520059 2023-08-23T17:53:16Z Damien Neil dneil@google.com 2023-08-08T21:07:08Z urn:sha1:f0b8768dbcf74bddedc32febd36732beb690b8aa Fix a bug where Clean could improperly drop .. elements from a path on Windows, when the path contains elements containing a ':'. For example, Clean("a/../b:/../../c") now correctly returns "..\c" rather than "c". For #61866. Fixes #61867. Change-Id: I97b0238953c183b2ce19ca89c14f26700008ea72 Reviewed-on: https://go-review.googlesource.com/c/go/+/517216 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> (cherry picked from commit 6e43407931ee4acc204620a9fae59c7903164901) Reviewed-on: https://go-review.googlesource.com/c/go/+/519636 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Damien Neil <dneil@google.com>