File _patchinfo of Package patchinfo.21306

<patchinfo incident="21306">
  <issue tracker="bnc" id="1190589">VUL-0: CVE-2021-39293: go1.14,go1.15,go1.16: archive/zip: overflow in preallocation check can cause OOM panic</issue>
  <issue tracker="bnc" id="1190649">go1.17 release tracking</issue>
  <issue tracker="cve" id="2021-39293"/>
  <packager>jfkw</packager>
  <rating>moderate</rating>
  <category>recommended</category>
  <summary>Recommended update for go1.17</summary>
  <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@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 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&#8211;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.

</description>
</patchinfo>
openSUSE Build Service is sponsored by