InTheForest/moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2026-01-11 10:41:43 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
28.x
moby/TESTING.md
Paweł Gronowski f7c40ea344 update to go1.24.8 
This minor release includes 10 security fixes following the security policy:

- net/mail: excessive CPU consumption in ParseAddress

    The ParseAddress function constructed domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this could cause excessive CPU consumption.

    Thanks to Philippe Antoine (Catena cyber) for reporting this issue.

    This is CVE-2025-61725 and Go issue https://go.dev/issue/75680.

- crypto/x509: quadratic complexity when checking name constraints

    Due to the design of the name constraint checking algorithm, the processing time
    of some inputs scales non-linearly with respect to the size of the certificate.

    This affects programs which validate arbitrary certificate chains.

    Thanks to Jakub Ciolek for reporting this issue.

    This is CVE-2025-58187 and Go issue https://go.dev/issue/75681.

- crypto/tls: ALPN negotiation errors can contain arbitrary text

    The crypto/tls conn.Handshake method returns an error on the server-side when
    ALPN negotation fails which can contain arbitrary attacker controlled
    information provided by the client-side of the connection which is not escaped.

    This affects programs which log these errors without any additional form of
    sanitization, and may allow injection of attacker controlled information into
    logs.

    Thanks to National Cyber Security Centre Finland for reporting this issue.

    This is CVE-2025-58189 and Go issue https://go.dev/issue/75652.

- encoding/pem: quadratic complexity when parsing some invalid inputs

    Due to the design of the PEM parsing function, the processing time for some
    inputs scales non-linearly with respect to the size of the input.

    This affects programs which parse untrusted PEM inputs.

    Thanks to Jakub Ciolek for reporting this issue.

    This is CVE-2025-61723 and Go issue https://go.dev/issue/75676.

- net/url: insufficient validation of bracketed IPv6 hostnames

    The Parse function permitted values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.

    Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua University for reporting this issue.

    This is CVE-2025-47912 and Go issue https://go.dev/issue/75678.

- encoding/asn1: pre-allocating memory when parsing DER payload can cause memory exhaustion

    When parsing DER payloads, memories were being allocated prior to fully validating the payloads.
    This permits an attacker to craft a big empty DER payload to cause memory exhaustion in functions such as asn1.Unmarshal, x509.ParseCertificateRequest, and ocsp.ParseResponse.

    Thanks to Jakub Ciolek for reporting this issue.

    This is CVE-2025-58185 and Go issue https://go.dev/issue/75671.

- net/http: lack of limit when parsing cookies can cause memory exhaustion

    Despite HTTP headers having a default limit of 1 MB, the number of cookies that can be parsed did not have a limit.
    By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.

    net/http now limits the number of cookies accepted to 3000, which can be adjusted using the httpcookiemaxnum GODEBUG option.

    Thanks to jub0bs for reporting this issue.

    This is CVE-2025-58186 and Go issue https://go.dev/issue/75672.

- crypto/x509: panic when validating certificates with DSA public keys

    Validating certificate chains which contain DSA public keys can cause programs
    to panic, due to a interface cast that assumes they implement the Equal method.

    This affects programs which validate arbitrary certificate chains.

    Thanks to Jakub Ciolek for reporting this issue.

    This is CVE-2025-58188 and Go issue https://go.dev/issue/75675.

- archive/tar: unbounded allocation when parsing GNU sparse map

    tar.Reader did not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions could cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input could result in large allocations.

    Thanks to Harshit Gupta (Mr HAX) - https://www.linkedin.com/in/iam-harshit-gupta/ for reporting this issue.

    This is CVE-2025-58183 and Go issue https://go.dev/issue/75677.

- net/textproto: excessive CPU consumption in Reader.ReadResponse

    The Reader.ReadResponse function constructed a response string through
    repeated string concatenation of lines. When the number of lines in a response is large,
    this could cause excessive CPU consumption.

    Thanks to Jakub Ciolek for reporting this issue.

    This is CVE-2025-61724 and Go issue https://go.dev/issue/75716.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit d7b4bb25bda9f86dc47bf5a8921ceb8b3a4a498c)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
2025-10-07 21:50:05 +02:00

4.5 KiB
Raw Permalink Blame History

Testing

This document contains the Moby code testing guidelines. It should answer any questions you may have as an aspiring Moby contributor.

Test suites

Moby has two test suites (and one legacy test suite):

  • Unit tests - use standard go test and gotest.tools/assert assertions. They are located in the package they test. Unit tests should be fast and test only their own package.
  • API integration tests - use standard go test and gotest.tools/assert assertions. They are located in ./integration/<component> directories, where component is: container, image, volume, etc. These tests perform HTTP requests to an API endpoint and check the HTTP response and daemon state after the call.

The legacy test suite integration-cli/ is deprecated. No new tests will be added to this suite. Any tests in this suite which require updates should be ported to either the unit test suite or the new API integration test suite.

Writing new tests

Most code changes will fall into one of the following categories.

Writing tests for new features

New code should be covered by unit tests. If the code is difficult to test with unit tests, then that is a good sign that it should be refactored to make it easier to reuse and maintain. Consider accepting unexported interfaces instead of structs so that fakes can be provided for dependencies.

If the new feature includes a completely new API endpoint then a new API integration test should be added to cover the success case of that endpoint.

If the new feature does not include a completely new API endpoint consider adding the new API fields to the existing test for that endpoint. A new integration test should not be added for every new API field or API error case. Error cases should be handled by unit tests.

Writing tests for bug fixes

Bugs fixes should include a unit test case which exercises the bug.

A bug fix may also include new assertions in existing integration tests for the API endpoint.

Writing new integration tests

Note the integration-cli tests are deprecated; new tests will be rejected by the CI.

Instead, implement new tests under integration/.

Integration tests environment considerations

When adding new tests or modifying existing tests under integration/, testing environment should be properly considered. skip.If from gotest.tools/skip can be used to make the test run conditionally. Full testing environment conditions can be found at environment.go

Here is a quick example. If the test needs to interact with a docker daemon on the same host, the following condition should be checked within the test code

skip.If(t, testEnv.IsRemoteDaemon())
// your integration test code

If a remote daemon is detected, the test will be skipped.

Running tests

Unit Tests

To run the unit test suite:

make test-unit

or hack/test/unit from inside a BINDDIR=. make shell container or properly configured environment.

The following environment variables may be used to run a subset of tests:

  • TESTDIRS - paths to directories to be tested, defaults to ./...
  • TESTFLAGS - flags passed to go test, to run tests which match a pattern use TESTFLAGS="-test.run TestNameOrPrefix"

Integration Tests

To run the integration test suite:

make test-integration

This make target runs both the "integration" suite and the "integration-cli" suite.

You can specify which integration test dirs to build and run by specifying the list of dirs in the TEST_INTEGRATION_DIR environment variable.

You can also explicitly skip either suite by setting (any value) in TEST_SKIP_INTEGRATION and/or TEST_SKIP_INTEGRATION_CLI environment variables.

Flags specific to each suite can be set in the TESTFLAGS_INTEGRATION and TESTFLAGS_INTEGRATION_CLI environment variables.

If all you want is to specify a test filter to run, you can set the TEST_FILTER environment variable. This ends up getting passed directly to go test -run (or go test -check-f, depending on the test suite). It will also automatically set the other above mentioned environment variables accordingly.

Go Version

You can change a version of golang used for building stuff that is being tested by setting GO_VERSION variable, for example:

make GO_VERSION=1.24.8 test
Reference in New Issue View Git Blame Copy Permalink