Log message:
go121: Support O_DIRECT on illumos.

Log message:
go121: Update to 1.21.9.

This minor release includes 1 security fix following the security policy:

http2: close connections when receiving too many headers

Maintaining HPACK state requires that we parse and process all HEADERS and
CONTINUATION frames on a connection. When a request's headers exceed
MaxHeaderBytes, we don't allocate memory to store the excess headers but we do
parse them. This permits an attacker to cause an HTTP/2 endpoint to read
arbitrary amounts of header data, all associated with a request which is going
to be rejected. These headers can include Huffman-encoded data which is
significantly more expensive for the receiver to decode than for an attacker to
send.

Set a limit on the amount of excess header frames we will process before
closing a connection.

Thanks to Bartek Nowotarski (https://nowotarski.info/) for reporting this
issue.

This is CVE-2023-45288 and Go issue https://go.dev/issue/65051.

Log message:
go121: Implement syscall.Mkfifo() on illumos.

Log message:
go121: update to 1.21.8 (security)

This minor release includes 5 security fixes following the security policy:

- crypto/x509: Verify panics on certificates with an unknown public key
  algorithm

  Verifying a certificate chain which contains a certificate with an unknown
  public key algorithm will cause Certificate.Verify to panic.

  This affects all crypto/tls clients, and servers that set Config.ClientAuth
  to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default
  behavior is for TLS servers to not verify client certificates.

  Thanks to John Howard (Google) for reporting this issue.

  This is CVE-2024-24783 and Go issue https://go.dev/issue/65390.

- net/http: memory exhaustion in Request.ParseMultipartForm

  When parsing a multipart form (either explicitly with
  Request.ParseMultipartForm or implicitly with Request.FormValue,
  Request.PostFormValue, or Request.FormFile), limits on the total size of the
  parsed form were not applied to the memory consumed while reading a single
  form line. This permitted a maliciously crafted input containing very long
  lines to cause allocation of arbitrarily large amounts of memory, potentially
  leading to memory exhaustion.

  ParseMultipartForm now correctly limits the maximum size of form lines.

  Thanks to Bartek Nowotarski for reporting this issue.

  This is CVE-2023-45290 and Go issue https://go.dev/issue/65383.

- net/http, net/http/cookiejar: incorrect forwarding of sensitive headers and
  cookies on HTTP redirect

  When following an HTTP redirect to a domain which is not a subdomain match or
  exact match of the initial domain, an http.Client does not forward sensitive
  headers such as "Authorization" or "Cookie". For example, \ 
a redirect from
  foo.com to www.foo.com will forward the Authorization header, but a redirect
  to bar.com will not.

  A maliciously crafted HTTP redirect could cause sensitive headers to be
  unexpectedly forwarded.

  Thanks to Juho Nurminen of Mattermost for reporting this issue.

  This is CVE-2023-45289 and Go issue https://go.dev/issue/65065.

- html/template: errors returned from MarshalJSON methods may break template
  escaping

  If errors returned from MarshalJSON methods contain user controlled data,
  they may be used to break the contextual auto-escaping behavior of the
  html/template package, allowing for subsequent actions to inject unexpected
  content into templates.

  Thanks to RyotaK (https://ryotak.net) for reporting this issue.

  This is CVE-2024-24785 and Go issue https://go.dev/issue/65697.

- net/mail: comments in display names are incorrectly handled

  The ParseAddressList function incorrectly handles comments (text within
  parentheses) within display names. Since this is a misalignment with
  conforming address parsers, it can result in different trust decisions being
  made by programs using different parsers.

  Thanks to Juho Nurminen of Mattermost and Slonser
  (https://github.com/Slonser) for reporting this issue.

  This is CVE-2024-24784 and Go issue https://go.dev/issue/65083.

Log message:
go121: update 1.21.7

go1.21.7 (released 2024-02-06) includes fixes to the compiler, the go command,
the runtime, and the crypto/x509 package. See the Go 1.21.7 milestone on the Go
issue tracker for details.

Log message:
go121: update to 1.21.6

go1.21.6 (released 2024-01-09) includes fixes to the compiler, the runtime, and
the crypto/tls, maps, and runtime/pprof packages.

It also includes a fix for a slow memory leak on Linux.

Log message:
go121: do not trim paths in the installed go tool

This fixes running "go build", "go env", etc. when /proc is \ 
not mounted on
NetBSD.

First reported by wiz@

Log message:
go121: update to 1.21.5 (security)

This minor release includes 3 security fixes following the security policy:

- net/http: limit chunked data overhead

  A malicious HTTP sender can use chunk extensions to cause a receiver reading
  from a request or response body to read many more bytes from the network than
  are in the body.

  A malicious HTTP client can further exploit this to cause a server to
  automatically read a large amount of data (up to about 1GiB) when a handler
  fails to read the entire body of a request.

  Chunk extensions are a little-used HTTP feature which permit including
  additional metadata in a request or response body sent using the chunked
  encoding. The net/http chunked encoding reader discards this metadata. A
  sender can exploit this by inserting a large metadata segment with each byte
  transferred. The chunk reader now produces an error if the ratio of real body
  to encoded bytes grows too small.

  Thanks to Bartek Nowotarski for reporting this issue.
  This is CVE-2023-39326 and Go issue https://go.dev/issue/64433.

- cmd/go: go get may unexpectedly fallback to insecure git

  Using go get to fetch a module with the ".git" suffix may unexpectedly
  fallback to the insecure "git://" protocol if the module is \ 
unavailable via
  the secure "https://" and "git+ssh://" protocols, even if \ 
GOINSECURE is not
  set for said module. This only affects users who are not using the module
  proxy and are fetching modules directly (i.e. GOPROXY=off).

  Thanks to David Leadbeater for reporting this issue.
  This is CVE-2023-45285 and Go issue https://go.dev/issue/63845.

- path/filepath: retain trailing \ when cleaning paths like \\?\c:\

  Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume
  name in Windows paths starting with \\?\, resulting in
  filepath.Clean(\\?\c:\) returning \\?\c: rather than \\?\c:\ (among other
  effects). The previous behavior has been restored.

  This is an update to CVE-2023-45283 and Go issue https://go.dev/issue/64028.