SUSE-RU-2021:3315-1

This update for go1.17 fixes the following issues:

This is the initial go 1.17 shipment.

go1.17.1 (released 2021-09-09) includes a security fix to the archive/zip package, as well as bug fixes to the compiler, linker, the go command, and to the crypto/rand, embed, go/types, html/template, and net/http packages. (bsc#1190649)

CVE-2021-39293: Fixed an overflow in preallocation check that can cause OOM panic in archive/zip (bsc#1190589)

go1.17 (released 2021-08-16) is a major release of Go.

go1.17.x minor releases will be provided through August 2022.

See https://github.com/golang/go/wiki/Go-Release-Cycle

Most changes are in the implementation of the toolchain, runtime, and libraries. As always, the release maintains the Go 1 promise of compatibility. We expect almost all Go programs to continue to compile and run as before. (bsc#1190649)

• See release notes https://golang.org/doc/go1.17. Excerpts relevant to OBS environment and for SUSE/openSUSE follow:
• The compiler now implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a typical reduction in binary size of about 2%. This is currently enabled for Linux, macOS, and Windows on the 64-bit x86 architecture (the linux/amd64, darwin/amd64, and windows/amd64 ports). This change does not affect the functionality of any safe Go code and is designed to have no impact on most assembly code.
• When the linker uses external linking mode, which is the default when linking a program that uses cgo, and the linker is invoked with a -I option, the option will now be passed to the external linker as a -Wl,--dynamic-linker option.
• The runtime/cgo package now provides a new facility that allows to turn any Go values to a safe representation that can be used to pass values between C and Go safely. See runtime/cgo.Handle for more information.
• ARM64 Go programs now maintain stack frame pointers on the 64-bit ARM architecture on all operating systems. Previously, stack frame pointers were only enabled on Linux, macOS, and iOS.
• Pruned module graphs in go 1.17 modules: If a module specifies go 1.17 or higher, the module graph includes only the immediate dependencies of other go 1.17 modules, not their full transitive dependencies. To convert the go.mod file for an existing module to Go 1.17 without changing the selected versions of its dependencies, run: go mod tidy -go=1.17 By default, go mod tidy verifies that the selected versions of dependencies relevant to the main module are the same versions that would be used by the prior Go release (Go 1.16 for a module that specifies go 1.17), and preserves the go.sum entries needed by that release even for dependencies that are not normally needed by other commands. The -compat flag allows that version to be overridden to support older (or only newer) versions, up to the version specified by the go directive in the go.mod file. To tidy a go 1.17 module for Go 1.17 only, without saving checksums for (or checking for consistency with) Go 1.16: go mod tidy -compat=1.17 Note that even if the main module is tidied with -compat=1.17, users who require the module from a go 1.16 or earlier module will still be able to use it, provided that the packages use only compatible language and library features. The go mod graph subcommand also supports the -go flag, which causes it to report the graph as seen by the indicated Go version, showing dependencies that may otherwise be pruned out.
• Module deprecation comments: Module authors may deprecate a module by adding a // Deprecated: comment to go.mod, then tagging a new version. go get now prints a warning if a module needed to build packages named on the command line is deprecated. go list -m -u prints deprecations for all dependencies (use -f or -json to show the full message). The go command considers different major versions to be distinct modules, so this mechanism may be used, for example, to provide users with migration instructions for a new major version.
• go get -insecure flag is deprecated and has been removed. To permit the use of insecure schemes when fetching dependencies, please use the GOINSECURE environment variable. The -insecure flag also bypassed module sum validation, use GOPRIVATE or GONOSUMDB if you need that functionality. See go help environment for details.
• go get prints a deprecation warning when installing commands outside the main module (without the -d flag). go install cmd@version should be used instead to install a command at a specific version, using a suffix like @latest or @v1.2.3. In Go 1.18, the -d flag will always be enabled, and go get will only be used to change dependencies in go.mod.
• go.mod files missing go directives: If the main module's go.mod file does not contain a go directive and the go command cannot update the go.mod file, the go command now assumes go 1.11 instead of the current release. (go mod init has added go directives automatically since Go 1.12.) If a module dependency lacks an explicit go.mod file, or its go.mod file does not contain a go directive, the go command now assumes go 1.16 for that dependency instead of the current release. (Dependencies developed in GOPATH mode may lack a go.mod file, and the vendor/modules.txt has to date never recorded the go versions indicated by dependencies' go.mod files.)
• vendor contents: If the main module specifies go 1.17 or higher, go mod vendor now annotates vendor/modules.txt with the go version indicated by each vendored module in its own go.mod file. The annotated version is used when building the module's packages from vendored source code. If the main module specifies go 1.17 or higher, go mod vendor now omits go.mod and go.sum files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree.
• Password prompts: The go command by default now suppresses SSH password prompts and Git Credential Manager prompts when fetching Git repositories using SSH, as it already did previously for other Git password prompts. Users authenticating to private Git repos with password-protected SSH may configure an ssh-agent to enable the go command to use password-protected SSH keys.
• go mod download: When go mod download is invoked without arguments, it will no longer save sums for downloaded module content to go.sum. It may still make changes to go.mod and go.sum needed to load the build list. This is the same as the behavior in Go 1.15. To save sums for all modules, use: go mod download all
• The go command now understands //go:build lines and prefers them over // +build lines. The new syntax uses boolean expressions, just like Go, and should be less error-prone. As of this release, the new syntax is fully supported, and all Go files should be updated to have both forms with the same meaning. To aid in migration, gofmt now automatically synchronizes the two forms. For more details on the syntax and migration plan, see https://golang.org/design/draft-gobuild.
• go run now accepts arguments with version suffixes (for example, go run example.com/cmd@v1.0.0). This causes go run to build and run packages in module-aware mode, ignoring the go.mod file in the current directory or any parent directory, if there is one. This is useful for running executables without installing them or without changing dependencies of the current module.
• The format of stack traces from the runtime (printed when an uncaught panic occurs, or when runtime.Stack is called) is improved.
• TLS strict ALPN: When Config.NextProtos is set, servers now enforce that there is an overlap between the configured protocols and the ALPN protocols advertised by the client, if any. If there is no mutually supported protocol, the connection is closed with the noapplicationprotocol alert, as required by RFC 7301. This helps mitigate the ALPACA cross-protocol attack. As an exception, when the value 'h2' is included in the server's Config.NextProtos, HTTP/1.1 clients will be allowed to connect as if they didn't support ALPN. See issue go#46310 for more information.
• crypto/ed25519: The crypto/ed25519 package has been rewritten, and all operations are now approximately twice as fast on amd64 and arm64. The observable behavior has not otherwise changed.
• crypto/elliptic: CurveParams methods now automatically invoke faster and safer dedicated implementations for known curves (P-224, P-256, and P-521) when available. Note that this is a best-effort approach and applications should avoid using the generic, not constant-time CurveParams methods and instead use dedicated Curve implementations such as P256. The P521 curve implementation has been rewritten using code generated by the fiat-crypto project, which is based on a formally-verified model of the arithmetic operations. It is now constant-time and three times faster on amd64 and arm64. The observable behavior has not otherwise changed.
• crypto/tls: The new Conn.HandshakeContext method allows the user to control cancellation of an in-progress TLS handshake. The provided context is accessible from various callbacks through the new ClientHelloInfo.Context and CertificateRequestInfo.Context methods. Canceling the context after the handshake has finished has no effect. Cipher suite ordering is now handled entirely by the crypto/tls package. Currently, cipher suites are sorted based on their security, performance, and hardware support taking into account both the local and peer's hardware. The order of the Config.CipherSuites field is now ignored, as well as the Config.PreferServerCipherSuites field. Note that Config.CipherSuites still allows applications to choose what TLS 1.0–1.2 cipher suites to enable. The 3DES cipher suites have been moved to InsecureCipherSuites due to fundamental block size-related weakness. They are still enabled by default but only as a last resort, thanks to the cipher suite ordering change above. Beginning in the next release, Go 1.18, the Config.MinVersion for crypto/tls clients will default to TLS 1.2, disabling TLS 1.0 and TLS 1.1 by default. Applications will be able to override the change by explicitly setting Config.MinVersion. This will not affect crypto/tls servers.
• crypto/x509: CreateCertificate now returns an error if the provided private key doesn't match the parent's public key, if any. The resulting certificate would have failed to verify.
• crypto/x509: The temporary GODEBUG=x509ignoreCN=0 flag has been removed.
• crypto/x509: ParseCertificate has been rewritten, and now consumes ~70% fewer resources. The observable behavior has not otherwise changed, except for error messages.
• crypto/x509: Beginning in the next release, Go 1.18, crypto/x509 will reject certificates signed with the SHA-1 hash function. This doesn't apply to self-signed root certificates. Practical attacks against SHA-1 have been demonstrated in 2017 and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.
• go/build: The new Context.ToolTags field holds the build tags appropriate to the current Go toolchain configuration.
• net/http package now uses the new (*tls.Conn).HandshakeContext with the Request context when performing TLS handshakes in the client or server.
• syscall: On Unix-like systems, the process group of a child process is now set with signals blocked. This avoids sending a SIGTTOU to the child when the parent is in a background process group.
• time: The new Time.IsDST method can be used to check whether the time is in Daylight Savings Time in its configured location.
• time: The new Time.UnixMilli and Time.UnixMicro methods return the number of milliseconds and microseconds elapsed since January 1, 1970 UTC respectively.

• time: The new UnixMilli and UnixMicro functions return the local Time corresponding to the given Unix time.

• Add bash scripts used by go tool commands to provide a more complete cross-compiling go toolchain install.