75e88d6837
go1.26.5 (released 2026-07-07) includes security fixes to the crypto/tls
and os packages, as well as bug fixes to the compiler, the runtime, the
go command, and the net, os, and syscall packages. See the Go 1.26.5
milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.26.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.26.4...go1.26.5
From the security announcement:
We have just released Go versions 1.26.5 and 1.25.12, minor point releases.
These releases include 2 security fixes following the security policy:
- os: Root escape via symlink plus trailing slash
On Unix systems, opening a file in an os.Root improperly
followed symlinks to locations outside of the Root when
the final path component of the a path is a symbolic link
and the path ends in /.
For example, root.Open("symlink/") would open "symlink"
even when "symlink" is a symbolic link pointing outside of the root.
On Unix, openat(fd, path, O_NOFOLLOW) will follow symlinks
in path when path ends in a /. Root failed to account for
this behavior, permitting paths with a trailing / to escape.
It now properly sanitizes the path parameter provided to openat.
hanks to Mundur for reporting this issue.
This is CVE-2026-39822 and Go issue https://go.dev/issue/79005.
- crypto/tls: Encrypted Client Hello privacy leak
he Encrypted Client Hello implementation would leak the pre-shared key
dentities during the handshake, allowing a passive network observer who can
ollect handshakes to de-anonymize the hostname of the server, even when ECH was
eing used.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2026-42505 and Go issue https://go.dev/issue/79282.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 44c855a73e)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Engine API
The Engine API is an HTTP API used by the command-line client to communicate with the daemon. It can also be used by third-party software to control the daemon.
It consists of various components in this repository:
api/swagger.yamlA Swagger definition of the API.api/types/Types shared by both the client and server, representing various objects, options, responses, etc. Most are written manually, but some are automatically generated from the Swagger definition. See #27919 for progress on this.client/The Go client used by the command-line client. It can also be used by third-party Go programs.daemon/The daemon, which serves the API.
Swagger definition
The API is defined by the Swagger definition in api/swagger.yaml. This definition can be used to:
- Automatically generate documentation.
- Automatically generate the Go server and client. (A work-in-progress.)
- Provide a machine readable version of the API for introspecting what it can do, automatically generating clients for other languages, etc.
Updating the API documentation
The API documentation is generated entirely from api/swagger.yaml. If you make updates to the API, edit this file to represent the change in the documentation.
Documentation for each API version can be found in the docs directory, which also provides a CHANGELOG.md.
The file is split into two main sections:
definitions, which defines re-usable objects used in requests and responsespaths, which defines the API endpoints (and some inline objects which don't need to be reusable)
To make an edit, first look for the endpoint you want to edit under paths, then make the required edits. Endpoints may reference reusable objects with $ref, which can be found in the definitions section.
There is hopefully enough example material in the file for you to copy a similar pattern from elsewhere in the file (e.g. adding new fields or endpoints), but for the full reference, see the Swagger specification.
swagger.yaml is validated by hack/validate/swagger to ensure it is a valid Swagger definition. This is useful when making edits to ensure you are doing the right thing.
Viewing the API documentation
When you make edits to swagger.yaml, you may want to check the generated API documentation to ensure it renders correctly.
Run make swagger-docs and a preview will be running at http://localhost:9000. Some of the styling may be incorrect, but you'll be able to ensure that it is generating the correct documentation.
The production documentation is generated by vendoring swagger.yaml into docker/docs.