go1.25.7 (released 2026-02-04) includes security fixes to the go command and the crypto/tls package, as well as bug fixes to the compiler and the crypto/x509 package. See the Go 1.25.7 milestone on our issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.25.7+label%3ACherryPickApproved full diff: https://github.com/golang/go/compare/go1.25.6...go1.25.7 From the security mailing list: > Hello gophers, > > We have just released Go versions 1.25.7 and 1.24.13, minor point releases. > > These releases include 2 security fixes following the security policy: > > - cmd/cgo: remove user-content from doc strings in cgo ASTs > > A discrepancy between how Go and C/C++ comments > were parsed allowed for code smuggling into the > resulting cgo binary. > > To prevent this behavior, the cgo compiler > will no longer parse user-provided doc > comments. > > Thank you to RyotaK (https://ryotak.net) of > GMO Flatt Security Inc. for reporting this issue. > > This is CVE-2025-61732 and https://go.dev/issue/76697. > > - crypto/tls: unexpected session resumption when using Config.GetConfigForClient > > Config.GetConfigForClient is documented to use the original Config's session > ticket keys unless explicitly overridden. This can cause unexpected behavior if > the returned Config modifies authentication parameters, like ClientCAs: a > connection initially established with the parent (or a sibling) Config can be > resumed, bypassing the modified authentication requirements. > > If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on the > server) or InsecureSkipVerify is false (on the client), crypto/tls now checks > that the root of the previously-verified chain is still in ClientCAs/RootCAs > when resuming a connection. > > Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar issue > related to session ticket keys being implicitly shared by Config.Clone. Since > this fix is broader, the Config.Clone behavior change has been reverted. > > Note that VerifyPeerCertificate still behaves as documented: it does not apply > to resumed connections. Applications that use Config.GetConfigForClient or > Config.Clone and do not wish to blindly resume connections established with the > original Config must use VerifyConnection instead (or SetSessionTicketKeys or > SessionTicketsDisabled). > > Thanks to Coia Prant (github.com/rbqvq) for reporting this issue. > > This updates CVE-2025-68121 and Go issue https://go.dev/issue/77217. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduction
docker-credential-helpers is a suite of programs to use native stores to keep Docker credentials safe.
Installation
Go to the Releases page and download the binary that works better for you. Put that binary in your $PATH, so Docker can find it.
Building
You can build the credential helpers using Docker:
# install emulators
$ docker run --privileged --rm tonistiigi/binfmt --install all
# create builder
$ docker buildx create --use
# build credential helpers from remote repository and output to ./bin/build
$ docker buildx bake "https://github.com/docker/docker-credential-helpers.git"
# or from local source
$ git clone https://github.com/docker/docker-credential-helpers.git
$ cd docker-credential-helpers
$ docker buildx bake
Or if the toolchain is already installed on your machine:
- Download the source.
$ git clone https://github.com/docker/docker-credential-helpers.git
$ cd docker-credential-helpers
- Use
maketo build the program you want. That will leave an executable in thebindirectory inside the repository.
$ make osxkeychain
- Put that binary in your
$PATH, so Docker can find it.
$ cp bin/build/docker-credential-osxkeychain /usr/local/bin/
Usage
With the Docker Engine
Set the credsStore option in your ~/.docker/config.json file with the suffix of the program you want to use. For instance, set it to osxkeychain if you want to use docker-credential-osxkeychain.
{
"credsStore": "osxkeychain"
}
With other command line applications
The sub-package client includes functions to call external programs from your own command line applications.
There are three things you need to know if you need to interact with a helper:
- The name of the program to execute, for instance
docker-credential-osxkeychain. - The server address to identify the credentials, for instance
https://example.com. - The username and secret to store, when you want to store credentials.
You can see examples of each function in the client documentation.
Available programs
- osxkeychain: Provides a helper to use the OS X keychain as credentials store.
- secretservice: Provides a helper to use the D-Bus secret service as credentials store.
- wincred: Provides a helper to use Windows credentials manager as store.
- pass: Provides a helper to use
passas credentials store.
Note
pass needs to be configured for docker-credential-pass to work properly.
It must be initialized with a gpg2 key ID. Make sure your GPG key exists is in gpg2 keyring as pass uses gpg2 instead of the regular gpg.
Development
A credential helper can be any program that can read values from the standard input. We use the first argument in the command line to differentiate the kind of command to execute. There are four valid values:
store: Adds credentials to the keychain. The payload in the standard input is a JSON document withServerURL,UsernameandSecret.get: Retrieves credentials from the keychain. The payload in the standard input is the raw value for theServerURL.erase: Removes credentials from the keychain. The payload in the standard input is the raw value for theServerURL.list: Lists stored credentials. There is no standard input payload.
This repository also includes libraries to implement new credentials programs in Go. Adding a new helper program is pretty easy. You can see how the OS X keychain helper works in the osxkeychain directory.
- Implement the interface
credentials.HelperinYOUR_PACKAGE/ - Create a main program in
YOUR_PACKAGE/cmd/. - Add make tasks to build your program and run tests.
License
MIT. See LICENSE for more information.