go1.20.8 (released 2023-09-06) includes two security fixes to the html/template
package, as well as bug fixes to the compiler, the go command, the runtime,
and the crypto/tls, go/types, net/http, and path/filepath packages. See the
Go 1.20.8 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.20.8+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.20.7...go1.20.8
From the security mailing:
[security] Go 1.21.1 and Go 1.20.8 are released
Hello gophers,
We have just released Go versions 1.21.1 and 1.20.8, minor point releases.
These minor releases include 4 security fixes following the security policy:
- cmd/go: go.mod toolchain directive allows arbitrary execution
The go.mod toolchain directive, introduced in Go 1.21, could be leveraged to
execute scripts and binaries relative to the root of the module when the "go"
command was executed within the module. This applies to modules downloaded using
the "go" command from the module proxy, as well as modules downloaded directly
using VCS software.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-39320 and Go issue https://go.dev/issue/62198.
- html/template: improper handling of HTML-like comments within script contexts
The html/template package did not properly handle HMTL-like "<!--" and "-->"
comment tokens, nor hashbang "#!" comment tokens, in <script> contexts. This may
cause the template parser to improperly interpret the contents of <script>
contexts, causing actions to be improperly escaped. This could be leveraged to
perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this
issue.
This is CVE-2023-39318 and Go issue https://go.dev/issue/62196.
- html/template: improper handling of special tags within script contexts
The html/template package did not apply the proper rules for handling occurrences
of "<script", "<!--", and "</script" within JS literals in <script> contexts.
This may cause the template parser to improperly consider script contexts to be
terminated early, causing actions to be improperly escaped. This could be
leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this
issue.
This is CVE-2023-39319 and Go issue https://go.dev/issue/62197.
- crypto/tls: panic when processing post-handshake message on QUIC connections
Processing an incomplete post-handshake message for a QUIC connection caused a panic.
Thanks to Marten Seemann for reporting this issue.
This is CVE-2023-39321 and CVE-2023-39322 and Go issue https://go.dev/issue/62266.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The new advanced --network syntax introduced in docker/cli#1767 is
lacking support for `link-local-ip` and `mac-address` fields. This
commit adds both.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Following flags are silently ignored when they're passed with no
`--network` specified (ie. when the default network is used):
- `--network-alias`
- `--ip`
- `--ip6`
- `--link-local-ip`
This is not really an issue right now since the first 3 parameters are
not allowed on the default bridge network. However, with
[moby/moby#45905][1], the container-wide MacAddress parameter will be
deprecated and dismissed. Because of that, with [docker/cli#4419][2],
it's currently not possible to use the `--mac-address` flag with no
default network specified.
Morever, `docker network connect --link-local-ip ...` works properly, so
it should also work on `docker container create`. This also lay the
ground for making the default bridge network just a "normal" network.
Since the 3 parameters in the list above aren't ignored anymore, if
users provide them, moby's ContainerStart endpoint will complain about
those. To provide better UX, [moby/moby#46183][3] make sure these
invalid parameters lead to a proper error message on `docker container
create` / `docker run`.
[1]: https://github.com/moby/moby/pull/45905
[2]: https://github.com/docker/cli/pull/4419
[3]: https://github.com/moby/moby/pull/46183
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
The latin phrase "vice versa" can be pronounced "vice-a-versa", but should not be rendered as such.
Signed-off-by: briantracy <brian.tracy33@gmail.com>
Remove some redundant error-checks or combine them. Also made a small
optimisation when initialising a slice.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn
Bjorn Neergaard
Sebastiaan van Stijn
dependabot[bot]
Albin Kerouanton
briantracy