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>
(cherry picked from commit 23115ff634)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This addresses CVE-2023-29402, CVE-2023-29403, CVE-2023-29404, CVE-2023-29405
which were patched in 1.19.10.
Signed-off-by: Ben Manuel <ben.manuel@procore.com>
(cherry picked from commit 36dd5b79ca)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removing the "structcheck" and "varcheck" linters as they've been deprecated.
level=warning msg="[runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused."
level=warning msg="[runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused."
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit dec03ea3d8)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We need to look into this; can we remove it, or is there a replacement?
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit ebe9d67446)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Client attempts to parse the body of every error it receives as JSON
regardless of the content-type. This commit rectifies by only parsing
he error body as JSON if the Content-Type header is set to
either "application/json" or "application/vnd.api+json".
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
(cherry picked from commit 45b7b9cec3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go requires "deprecated" comments to have an empty line before them,
and to not be all-caps.
This updates to the comment so that it's correctly picked up as deprecated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 3c71f4933d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It would appear we were missing the Go build tags on 2.8.X branch so the
images would not have the necessary support for some storage drivers
causing breakages to end users trying to use them.
This commit fixes both the build and linting issues.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
This was added for the other drivers in 6b388b1ba6,
but it missed the s3 storage driver.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 5b3be39870)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This enables go build tags so the GCS and OSS driver support is
available in the binary distributed via the image build by Dockerfile.
This led to quite a few fixes in the GCS and OSS packages raised as
warning by golang-ci linter.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
(cherry picked from commit 6b388b1ba6)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Added back minor versions in these, so that we have a somewhat more
reproducible state in the repository when tagging releases.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 322eb4eecf)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduced a Catalog entry in the configuration struct. With it,
it's possible to control the maximum amount of entries returned
by /v2/catalog (`GetCatalog` in registry/handlers/catalog.go).
It's set to a default value of 1000.
`GetCatalog` returns 100 entries by default if no `n` is
provided. When provided it will be validated to be between `0`
and `MaxEntries` defined in Configuration. When `n` is outside
the aforementioned boundary, ErrorCodePaginationNumberInvalid is
returned.
`GetCatalog` now handles `n=0` gracefully with an empty response
as well.
Signed-off-by: José D. Gómez R. <1josegomezr@gmail.com>
Co-authored-by: Cory Snider <corhere@gmail.com>
