2022-08-19 10:50:01 -04:00
|
|
|
# syntax=docker/dockerfile:1
|
2017-05-02 15:10:03 -04:00
|
|
|
|
[20.10] update go to go1.19.8
go1.19.8 (released 2023-04-04) includes security fixes to the go/parser,
html/template, mime/multipart, net/http, and net/textproto packages, as well as
bug fixes to the linker, the runtime, and the time package. See the Go 1.19.8
milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.19.8+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.19.7...go1.19.8
Further details from the announcement on the mailing list:
We have just released Go versions 1.20.3 and 1.19.8, minor point releases.
These minor releases include 4 security fixes following the security policy:
- go/parser: infinite loop in parsing
Calling any of the Parse functions on Go source code which contains `//line`
directives with very large line numbers can cause an infinite loop due to
integer overflow.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2023-24537 and Go issue https://go.dev/issue/59180.
- html/template: backticks not treated as string delimiters
Templates did not properly consider backticks (`) as Javascript string
delimiters, and as such did not escape them as expected. Backticks are
used, since ES6, for JS template literals. If a template contained a Go
template action within a Javascript template literal, the contents of the
action could be used to terminate the literal, injecting arbitrary Javascript
code into the Go template.
As ES6 template literals are rather complex, and themselves can do string
interpolation, we've decided to simply disallow Go template actions from being
used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe
way to allow this behavior. This takes the same approach as
github.com/google/safehtml. Template.Parse will now return an Error when it
encounters templates like this, with a currently unexported ErrorCode with a
value of 12. This ErrorCode will be exported in the next major release.
Users who rely on this behavior can re-enable it using the GODEBUG flag
jstmpllitinterp=1, with the caveat that backticks will now be escaped. This
should be used with caution.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this issue.
This is CVE-2023-24538 and Go issue https://go.dev/issue/59234.
- net/http, net/textproto: denial of service from excessive memory allocation
HTTP and MIME header parsing could allocate large amounts of memory, even when
parsing small inputs.
Certain unusual patterns of input data could cause the common function used to
parse HTTP and MIME headers to allocate substantially more memory than
required to hold the parsed headers. An attacker can exploit this behavior to
cause an HTTP server to allocate large amounts of memory from a small request,
potentially leading to memory exhaustion and a denial of service.
Header parsing now correctly allocates only the memory required to hold parsed
headers.
Thanks to Jakob Ackermann (@das7pad) for discovering this issue.
This is CVE-2023-24534 and Go issue https://go.dev/issue/58975.
- net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption
Multipart form parsing can consume large amounts of CPU and memory when
processing form inputs containing very large numbers of parts. This stems from
several causes:
mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form
can consume. ReadForm could undercount the amount of memory consumed, leading
it to accept larger inputs than intended. Limiting total memory does not
account for increased pressure on the garbage collector from large numbers of
small allocations in forms with many parts. ReadForm could allocate a large
number of short-lived buffers, further increasing pressure on the garbage
collector. The combination of these factors can permit an attacker to cause an
program that parses multipart forms to consume large amounts of CPU and
memory, potentially resulting in a denial of service. This affects programs
that use mime/multipart.Reader.ReadForm, as well as form parsing in the
net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm now does a better job of estimating the memory consumption of parsed
forms, and performs many fewer short-lived allocations.
In addition, mime/multipart.Reader now imposes the following limits on the
size of parsed forms:
Forms parsed with ReadForm may contain no more than 1000 parts. This limit may
be adjusted with the environment variable GODEBUG=multipartmaxparts=. Form
parts parsed with NextPart and NextRawPart may contain no more than 10,000
header fields. In addition, forms parsed with ReadForm may contain no more
than 10,000 header fields across all parts. This limit may be adjusted with
the environment variable GODEBUG=multipartmaxheaders=.
Thanks to Jakob Ackermann for discovering this issue.
This is CVE-2023-24536 and Go issue https://go.dev/issue/59153.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-04-05 09:50:41 -04:00
|
|
|
ARG GO_VERSION=1.19.8
|
2022-12-04 08:01:30 -05:00
|
|
|
ARG ALPINE_VERSION=3.16
|
2022-09-02 15:24:26 -04:00
|
|
|
ARG GOLANGCI_LINT_VERSION=v1.49.0
|
2017-05-02 15:10:03 -04:00
|
|
|
|
2022-12-04 08:01:30 -05:00
|
|
|
FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS build
|
2019-04-02 11:27:12 -04:00
|
|
|
ENV CGO_ENABLED=0
|
|
|
|
|
RUN apk add --no-cache git
|
2022-08-19 10:52:49 -04:00
|
|
|
ARG GOLANGCI_LINT_VERSION
|
2019-04-02 11:27:12 -04:00
|
|
|
ARG GO111MODULE=on
|
|
|
|
|
RUN --mount=type=cache,target=/root/.cache/go-build \
|
|
|
|
|
--mount=type=cache,target=/go/pkg/mod \
|
2022-08-19 10:52:49 -04:00
|
|
|
go install github.com/golangci/golangci-lint/cmd/golangci-lint@${GOLANGCI_LINT_VERSION}
|
2017-05-02 15:10:03 -04:00
|
|
|
|
2022-12-04 08:01:30 -05:00
|
|
|
FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS lint
|
2021-07-15 09:15:38 -04:00
|
|
|
ENV GO111MODULE=off
|
2017-06-09 12:32:14 -04:00
|
|
|
ENV CGO_ENABLED=0
|
2017-08-15 14:32:44 -04:00
|
|
|
ENV DISABLE_WARN_OUTSIDE_CONTAINER=1
|
2019-04-02 11:27:12 -04:00
|
|
|
COPY --from=build /go/bin/golangci-lint /usr/local/bin
|
|
|
|
|
WORKDIR /go/src/github.com/docker/cli
|
|
|
|
|
ENV GOGC=75
|
|
|
|
|
ENTRYPOINT ["/usr/local/bin/golangci-lint"]
|
|
|
|
|
CMD ["run", "--config=.golangci.yml"]
|
Do not patch Dockerfiles in CI
When building the Dockerfiles for development, those images are mainly used to
create a reproducible build-environment. The source code is bind-mounted into
the image at runtime; there is no need to create an image with the actual
source code, and copying the source code into the image would lead to a new
image being created for each code-change (possibly leading up to many "dangling"
images for previous code-changes).
However, when building (and using) the development images in CI, bind-mounting
is not an option, because the daemon is running remotely.
To make this work, the circle-ci script patched the Dockerfiles when CI is run;
adding a `COPY` to the respective Dockerfiles.
Patching Dockerfiles is not really a "best practice" and, even though the source
code does not and up in the image, the source would still be _sent_ to the daemon
for each build (unless BuildKit is used).
This patch updates the makefiles, circle-ci script, and Dockerfiles;
- When building the Dockerfiles locally, pipe the Dockerfile through stdin.
Doing so, prevents the build-context from being sent to the daemon. This speeds
up the build, and doesn't fill up the Docker "temp" directory with content that's
not used
- Now that no content is sent, add the COPY instructions to the Dockerfiles, and
remove the code in the circle-ci script to "live patch" the Dockerfiles.
Before this patch is applied (with cache):
```
$ time make -f docker.Makefile build_shell_validate_image
docker build -t docker-cli-shell-validate -f ./dockerfiles/Dockerfile.shellcheck .
Sending build context to Docker daemon 41MB
Step 1/2 : FROM debian:stretch-slim
...
Successfully built 81e14e8ad856
Successfully tagged docker-cli-shell-validate:latest
2.75 real 0.45 user 0.56 sys
```
After this patch is applied (with cache)::
```
$ time make -f docker.Makefile build_shell_validate_image
cat ./dockerfiles/Dockerfile.shellcheck | docker build -t docker-cli-shell-validate -
Sending build context to Docker daemon 2.048kB
Step 1/2 : FROM debian:stretch-slim
...
Successfully built 81e14e8ad856
Successfully tagged docker-cli-shell-validate:latest
0.33 real 0.07 user 0.08 sys
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2018-11-28 19:06:10 -05:00
|
|
|
COPY . .
|
