summaryrefslogtreecommitdiff
path: root/.github/workflows
Commit message (Collapse)AuthorAgeFilesLines
* ci: bin-image workflowCrazyMax2023-05-111-0/+72
| | | | | | This workflow will just build the bin-image bake target. Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* update go to go1.20.4Sebastiaan van Stijn2023-05-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | go1.20.4 (released 2023-05-02) includes three security fixes to the html/template package, as well as bug fixes to the compiler, the runtime, and the crypto/subtle, crypto/tls, net/http, and syscall packages. See the Go 1.20.4 milestone on our issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.20.4+label%3ACherryPickApproved release notes: https://go.dev/doc/devel/release#go1.20.4 full diff: https://github.com/golang/go/compare/go1.20.3...go1.20.4 from the announcement: > These minor releases include 3 security fixes following the security policy: > > - html/template: improper sanitization of CSS values > > Angle brackets (`<>`) were not considered dangerous characters when inserted > into CSS contexts. Templates containing multiple actions separated by a '/' > character could result in unexpectedly closing the CSS context and allowing > for injection of unexpected HMTL, if executed with untrusted input. > > Thanks to Juho Nurminen of Mattermost for reporting this issue. > > This is CVE-2023-24539 and Go issue https://go.dev/issue/59720. > > - html/template: improper handling of JavaScript whitespace > > Not all valid JavaScript whitespace characters were considered to be > whitespace. Templates containing whitespace characters outside of the character > set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also contain > actions may not be properly sanitized during execution. > > Thanks to Juho Nurminen of Mattermost for reporting this issue. > > This is CVE-2023-24540 and Go issue https://go.dev/issue/59721. > > - html/template: improper handling of empty HTML attributes > > Templates containing actions in unquoted HTML attributes (e.g. "attr={{.}}") > executed with empty input could result in output that would have unexpected > results when parsed due to HTML normalization rules. This may allow injection > of arbitrary attributes into tags. > > Thanks to Juho Nurminen of Mattermost for reporting this issue. > > This is CVE-2023-29400 and Go issue https://go.dev/issue/59722. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Added timeout to validate job in github actionsAneesh Kulkarni2023-04-111-0/+1
| | | | Signed-off-by: Aneesh Kulkarni <askthefactorcamera@gmail.com>
* update go to go1.20.3Sebastiaan van Stijn2023-04-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | go1.20.3 (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 compiler, the linker, the runtime, and the time package. See the Go 1.20.3 milestone on our issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.20.3+label%3ACherryPickApproved full diff: https://github.com/golang/go/compare/go1.20.2...go1.20.3 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>
* Skip Buildkit digest testsLaura Brehm2023-03-301-1/+2
| | | | | | (see https://github.com/moby/buildkit/pull/3736) Signed-off-by: Laura Brehm <laurabrehm@hey.com>
* vendor: github.com/moby/buildkit v0.11.5Sebastiaan van Stijn2023-03-251-3/+1
| | | | | | full diff: https://github.com/moby/buildkit/compare/v0.11.4...v0.11.5 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* ci: disable testing mergeop and diffop with the dockerd workerBjorn Neergaard2023-03-161-0/+3
| | | | | Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com> Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
* ci: enable BuildKit tests with containerd integration workerCrazyMax2023-03-161-3/+14
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* update to go1.20.2Sebastiaan van Stijn2023-03-102-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Includes a security fix for crypto/elliptic (CVE-2023-24532). > go1.20.2 (released 2023-03-07) includes a security fix to the crypto/elliptic package, > as well as bug fixes to the compiler, the covdata command, the linker, the runtime, and > the crypto/ecdh, crypto/rsa, crypto/x509, os, and syscall packages. > See the Go 1.20.2 milestone on our issue tracker for details. https://go.dev/doc/devel/release#go1.20.minor From the announcement: > We have just released Go versions 1.20.2 and 1.19.7, minor point releases. > > These minor releases include 1 security fixes following the security policy: > > - crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results > > The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an > incorrect result if called with some specific unreduced scalars (a scalar larger > than the order of the curve). > > This does not impact usages of crypto/ecdsa or crypto/ecdh. > > This is CVE-2023-24532 and Go issue https://go.dev/issue/58647. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Upgrade to Go 1.20.1Cory Snider2023-02-222-2/+2
| | | | Signed-off-by: Cory Snider <csnider@mirantis.com>
* Upgrade to Go 1.20Bjorn Neergaard2023-02-222-2/+2
| | | | | | Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com> Co-authored-by: Cory Snider <csnider@mirantis.com> Signed-off-by: Cory Snider <csnider@mirantis.com>
* update to go1.19.6Sebastiaan van Stijn2023-02-172-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | go1.19.6 (released 2023-02-14) includes security fixes to the crypto/tls, mime/multipart, net/http, and path/filepath packages, as well as bug fixes to the go command, the linker, the runtime, and the crypto/x509, net/http, and time packages. See the Go 1.19.6 milestone on our issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.19.6+label%3ACherryPickApproved From the announcement on the security mailing: We have just released Go versions 1.20.1 and 1.19.6, minor point releases. These minor releases include 4 security fixes following the security policy: - path/filepath: path traversal in filepath.Clean on Windows On Windows, the filepath.Clean function could transform an invalid path such as a/../c:/b into the valid path c:\b. This transformation of a relative (if invalid) path into an absolute path could enable a directory traversal attack. The filepath.Clean function will now transform this path into the relative (but still invalid) path .\c:\b. This is CVE-2022-41722 and Go issue https://go.dev/issue/57274. - net/http, mime/multipart: denial of service from excessive resource consumption Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map ntry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader. This is CVE-2022-41725 and Go issue https://go.dev/issue/58006. - crypto/tls: large handshake records may cause panics Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth > = RequestClientCert). This is CVE-2022-41724 and Go issue https://go.dev/issue/58001. - net/http: avoid quadratic complexity in HPACK decoding A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests. This issue is also fixed in golang.org/x/net/http2 v0.7.0, for users manually configuring HTTP/2. This is CVE-2022-41723 and Go issue https://go.dev/issue/57855. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Merge pull request #44920 from tonistiigi/worker-getremotesSebastiaan van Stijn2023-02-071-3/+1
|\ | | | | builder: define GetRemotes for the worker
| * vendor: update buildkit to latest v0.11Tonis Tiigi2023-02-071-3/+1
| | | | | | | | Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
* | ci: fix branch filter pattern in buildkit workflowCrazyMax2023-02-071-1/+1
|/ | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* ci: enhance tests distributionCrazyMax2023-02-072-8/+11
| | | | | | | Adds overrides with specific tests suites in our tests matrix so we can reduce build time significantly. Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* ci: update gotestlist to 0.3.1Kevin Alvarez2023-02-072-2/+2
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* gha: switch buildkit back to upstream for testingSebastiaan van Stijn2023-02-061-4/+3
| | | | | | | | | | commit 043dbc05dfacfe3d8bc2e7297fa78e861c89cd85 temporarily switched to a fork of BuildKit to workaround a failure in CI. These fixes have been backported to the v0.11 branch in BuildKit, so we can switch back to upstream. We can remove this override once we update vendor.mod to BuildKit v0.11.3. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* github: apply patch for CNI test that was incorrectly skippedTonis Tiigi2023-02-011-2/+6
| | | | Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
* vendor: update buildkit to v0.11.2Tonis Tiigi2023-02-011-3/+1
| | | | Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
* Dockerfile: smoke tests for static buildsCrazyMax2023-01-181-0/+52
| | | | | | | Adds smoke test stage in our Dockerfile and a GitHub Action workflow Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* update to go1.19.5Sebastiaan van Stijn2023-01-112-2/+2
| | | | | | | | | | | | go1.19.5 (released 2023-01-10) includes fixes to the compiler, the linker, and the crypto/x509, net/http, sync/atomic, and syscall packages. See the Go 1.19.5 milestone on the issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.19.5+label%3ACherryPickApproved full diff: https://github.com/golang/go/compare/go1.19.4...go1.19.5 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* ci: update buildkit to fix integration testsCrazyMax2023-01-101-1/+1
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* Dockerfile: add "all" stage to build binaries and extra toolsCrazyMax2023-01-011-1/+1
| | | | | | | | | | We still need a stage that build binaries and extra tools as well for docker-ce-packaging repo: https://github.com/docker/docker-ce-packaging/blob/ff110508ffce04a9246ef52af4e7a458422e941a/static/Makefile#L41-L57 This could be removed if we create a package for each project like it's done in docker-packaging repo: https://github.com/docker/packaging/tree/main/pkg Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* ci: add extra steps to check artifactsCrazyMax2023-01-011-0/+16
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* bake: define DESTDIRCrazyMax2023-01-012-6/+6
| | | | | | | Keep the same output dir format in the bake definition as the one used in make scripts. Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* Dockerfile: use TARGETPLATFORM to build DockerCrazyMax2023-01-011-13/+26
| | | | | | | | | | | | | | | | Better support for cross compilation so we can fully rely on `--platform` flag of buildx for a seamless integration. This removes unnecessary extra cross logic in the Dockerfile, DOCKER_CROSSPLATFORMS and CROSS vars and some hack scripts as well. Non-sandboxed build invocation is still supported and dev stages in the Dockerfile have been updated accordingly. Bake definition and GitHub Actions workflows have been updated accordingly as well. Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* gha: update buildkit to fix integration testsSebastiaan van Stijn2022-12-271-1/+1
| | | | | | full diff: https://github.com/moby/buildkit/compare/0bfcd83e6db95e6c6877ee6e5224b994cea62ba1...d77361423c88cc2a0d19e285ec3599022e92571f Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* hack: replace go-mod-prepare.sh with wrapper scriptBjorn Neergaard2022-12-121-1/+0
| | | | | | | | | | | | | To make the local build environment more correct and consistent, we should never leave an uncommitted go.mod in the tree; however, we need a go.mod for certain commands to work properly. Use a wrapper script to create and destroy the go.mod as needed instead of potentially changing tooling behavior by leaving it. If a go.mod already exists, this script will warn and call the wrapped command with GO111MODULE=on. Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
* update to go1.19.4Sebastiaan van Stijn2022-12-062-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Includes security fixes for net/http (CVE-2022-41717, CVE-2022-41720), and os (CVE-2022-41720). These minor releases include 2 security fixes following the security policy: - os, net/http: avoid escapes from os.DirFS and http.Dir on Windows The os.DirFS function and http.Dir type provide access to a tree of files rooted at a given directory. These functions permitted access to Windows device files under that root. For example, os.DirFS("C:/tmp").Open("COM1") would open the COM1 device. Both os.DirFS and http.Dir only provide read-only filesystem access. In addition, on Windows, an os.DirFS for the directory \(the root of the current drive) can permit a maliciously crafted path to escape from the drive and access any path on the system. The behavior of os.DirFS("") has changed. Previously, an empty root was treated equivalently to "/", so os.DirFS("").Open("tmp") would open the path "/tmp". This now returns an error. This is CVE-2022-41720 and Go issue https://go.dev/issue/56694. - net/http: limit canonical header cache by bytes, not entries An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection. This issue is also fixed in golang.org/x/net/http2 vX.Y.Z, for users manually configuring HTTP/2. Thanks to Josselin Costanzi for reporting this issue. This is CVE-2022-41717 and Go issue https://go.dev/issue/56350. View the release notes for more information: https://go.dev/doc/devel/release#go1.19.4 And the milestone on the issue tracker: https://github.com/golang/go/issues?q=milestone%3AGo1.19.4+label%3ACherryPickApproved Full diff: https://github.com/golang/go/compare/go1.19.3...go1.19.4 The golang.org/x/net fix is in https://github.com/golang/net/commit/1e63c2f08a10a150fa02c50ece89b340ae64efe4 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* ci(buildkit): update buildkit ref to fix issue with alpine imageKevin Alvarez2022-12-021-1/+1
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* Merge pull request #44533 from crazy-max/makefile-use-buildxBrian Goff2022-11-281-2/+0
|\ | | | | Makefile: always use buildx
| * Makefile: always use buildxCrazyMax2022-11-251-2/+0
| | | | | | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* | ci: define timeout for jobsCrazyMax2022-11-253-1/+9
|/ | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* vendor: github.com/moby/buildkit v0.10.6Sebastiaan van Stijn2022-11-141-1/+1
| | | | | | full diff: https://github.com/moby/buildkit/compare/v0.10.5...v0.10.6 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* ci(actions): bump outdated actions on LinuxBjorn Neergaard2022-11-101-5/+5
| | | | Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
* ci(actions): migrate to file-based commandsBjorn Neergaard2022-11-102-3/+3
| | | | Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
* Update to Go 1.19.3 to address CVE-2022-41716Cory Snider2022-11-012-2/+2
| | | | | | | | | | | | | | | | | | | | | On Windows, syscall.StartProcess and os/exec.Cmd did not properly check for invalid environment variable values. A malicious environment variable value could exploit this behavior to set a value for a different environment variable. For example, the environment variable string "A=B\x00C=D" set the variables "A=B" and "C=D". Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue. This is CVE-2022-41716 and Go issue https://go.dev/issue/56284. This Go release also fixes https://github.com/golang/go/issues/56309, a runtime bug which can cause random memory corruption when a goroutine exits with runtime.LockOSThread() set. This fix is necessary to unblock work to replace certain uses of pkg/reexec with unshared OS threads. Signed-off-by: Cory Snider <csnider@mirantis.com>
* Merge pull request #44337 from thaJeztah/buildkit_skip_unitSebastiaan van Stijn2022-10-211-10/+6
|\ | | | | gha: buildkit: remove "skip-integration-tests" from matrix
| * gha: buildkit: make checks more readableSebastiaan van Stijn2022-10-201-6/+6
| | | | | | | | | | | | | | GitHub uses these parameters to construct a name; removing the ./ prefix to make them more readable (and add them back where it's used) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
| * gha: buildkit: remove "skip-integration-tests" from matrixSebastiaan van Stijn2022-10-201-4/+0
| | | | | | | | Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* | gha: update buildkit to v0.10.5-6-ge27c8e24 to skip some testsSebastiaan van Stijn2022-10-201-2/+2
|/ | | | | | full diff: https://github.com/moby/buildkit/compare/v0.10.5...v0.10.5-6-ge27c8e24 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Update to go 1.19.2 to address CVE-2022-2879, CVE-2022-2880, CVE-2022-41715Sebastiaan van Stijn2022-10-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the mailing list: We have just released Go versions 1.19.2 and 1.18.7, minor point releases. These minor releases include 3 security fixes following the security policy: - archive/tar: unbounded memory consumption when reading headers Reader.Read did not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. Reader.Read now limits the maximum size of header blocks to 1 MiB. Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue. This is CVE-2022-2879 and Go issue https://go.dev/issue/54853. - net/http/httputil: ReverseProxy should not forward unparseable query parameters Requests forwarded by ReverseProxy included the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. ReverseProxy will now sanitize the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy.Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged. Thanks to Gal Goldstein (Security Researcher, Oxeye) and Daniel Abeles (Head of Research, Oxeye) for reporting this issue. This is CVE-2022-2880 and Go issue https://go.dev/issue/54663. - regexp/syntax: limit memory used by parsing regexps The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. Each regexp being parsed is now limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are now rejected. Normal use of regular expressions is unaffected. Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue. This is CVE-2022-41715 and Go issue https://go.dev/issue/55949. View the release notes for more information: https://go.dev/doc/devel/release#go1.19.2 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* ci: reduce cache throttling limitsCrazyMax2022-09-212-9/+0
| | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* Merge pull request #44134 from crazy-max/test-summarySebastiaan van Stijn2022-09-211-0/+79
|\ | | | | ci(test): report summary output
| * ci(test): report summary outputCrazyMax2022-09-121-0/+79
| | | | | | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* | ci: fix branch filter patternCrazyMax2022-09-203-3/+3
| | | | | | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* | ci: reusable dco workflowCrazyMax2022-09-107-25/+79
| | | | | | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* | ci(test): dynamic validate matrixCrazyMax2022-09-101-13/+23
| | | | | | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
* | ci(test): validate job matrixCrazyMax2022-09-091-0/+69
|/ | | | Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
View Lorry Controller Status