SUSE-RU-2021:3315-1: moderate: Recommended update for go1.17
sle-updates at lists.suse.com
sle-updates at lists.suse.com
Wed Oct 6 22:21:37 UTC 2021
SUSE Recommended Update: Recommended update for go1.17
______________________________________________________________________________
Announcement ID: SUSE-RU-2021:3315-1
Rating: moderate
References: #1190589 #1190649
Affected Products:
SUSE Linux Enterprise Module for Development Tools 15-SP3
SUSE Linux Enterprise Module for Development Tools 15-SP2
______________________________________________________________________________
An update that solves one vulnerability and has one errata
is now available.
Description:
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 at 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 at 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
no_application_protocol 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.
Patch Instructions:
To install this SUSE Recommended Update use the SUSE recommended installation methods
like YaST online_update or "zypper patch".
Alternatively you can run the command listed for your product:
- SUSE Linux Enterprise Module for Development Tools 15-SP3:
zypper in -t patch SUSE-SLE-Module-Development-Tools-15-SP3-2021-3315=1
- SUSE Linux Enterprise Module for Development Tools 15-SP2:
zypper in -t patch SUSE-SLE-Module-Development-Tools-15-SP2-2021-3315=1
Package List:
- SUSE Linux Enterprise Module for Development Tools 15-SP3 (aarch64 ppc64le s390x x86_64):
go1.17-1.17.1-1.3.1
go1.17-doc-1.17.1-1.3.1
- SUSE Linux Enterprise Module for Development Tools 15-SP3 (aarch64 x86_64):
go1.17-race-1.17.1-1.3.1
- SUSE Linux Enterprise Module for Development Tools 15-SP2 (aarch64 ppc64le s390x x86_64):
go1.17-1.17.1-1.3.1
go1.17-doc-1.17.1-1.3.1
- SUSE Linux Enterprise Module for Development Tools 15-SP2 (aarch64 x86_64):
go1.17-race-1.17.1-1.3.1
References:
https://www.suse.com/security/cve/CVE-2021-39293.html
https://bugzilla.suse.com/1190589
https://bugzilla.suse.com/1190649
More information about the sle-updates
mailing list