Description
I'm having a nil pointer on the docker daemon when trying to push an image to an (internal, unauthenticated) registry through the docker-py module.
Stack trace is attached stacktrace.txt.
From what I could gather, the python's module doesn't pass the X-Registry-Auth header if the auth_config is None around here (external repo).
That causes the var authConfig *registry.AuthConfig to never be initialized. reference at v28.3.3,
Which later causes the nil pointer dereference later on here
The workaround that we're using is passing an empty dict auth_config on the python client, but it feels like it's a daemon/moby problem.
As a side note, I noticed the docker CLI passes an empty dict ({}) in the header. The python module could do that, but doesn't solve the nil pointer dereference possibility.
Reproduce
(It feels like it could be anything, but maybe not)
Python script
import docker
cli = docker.from_env()
result = cli.images.push("localhost:5000/some-image", tag="some-tag", stream="False") # auth_config=None (default)Expected behavior
At least the docker daemon doesn't panic.
docker version
Client: Docker Engine - Community
Version: 28.3.3
API version: 1.51
Go version: go1.24.5
Git commit: 980b856
Built: Fri Jul 25 11:34:09 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 28.3.3
API version: 1.51 (minimum version 1.24)
Go version: go1.24.5
Git commit: bea959c
Built: Fri Jul 25 11:34:09 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client: Docker Engine - Community
Version: 28.3.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.26.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.39.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 3
Server Version: 28.3.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.14.0-27-generic
Operating System: Ubuntu 24.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.47GiB
Name: ppc-1
ID: 440888d1-da88-4d1b-a962-7cdf4c285c65
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 49
Goroutines: 146
System Time: 2025-08-14T10:35:43.141158417+02:00
EventsListeners: 0
Experimental: false
Insecure Registries:
192.168.1.5:4444
::1/128
127.0.0.0/8
Live Restore Enabled: falseAdditional Info
As a possible fix, I'm assuming have a default empty value for the authConfig would suffice.
Description
I'm having a nil pointer on the docker daemon when trying to push an image to an (internal, unauthenticated) registry through the docker-py module.
Stack trace is attached stacktrace.txt.
From what I could gather, the python's module doesn't pass the
X-Registry-Authheader if theauth_configisNonearound here (external repo).That causes the
var authConfig *registry.AuthConfigto never be initialized. reference at v28.3.3,Which later causes the nil pointer dereference later on here
The workaround that we're using is passing an empty dict auth_config on the python client, but it feels like it's a daemon/moby problem.
As a side note, I noticed the docker CLI passes an empty dict (
{}) in the header. The python module could do that, but doesn't solve the nil pointer dereference possibility.Reproduce
(It feels like it could be anything, but maybe not)
Python script
Expected behavior
At least the docker daemon doesn't panic.
docker version
Client: Docker Engine - Community Version: 28.3.3 API version: 1.51 Go version: go1.24.5 Git commit: 980b856 Built: Fri Jul 25 11:34:09 2025 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 28.3.3 API version: 1.51 (minimum version 1.24) Go version: go1.24.5 Git commit: bea959c Built: Fri Jul 25 11:34:09 2025 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.7.27 GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da runc: Version: 1.2.5 GitCommit: v1.2.5-0-g59923ef docker-init: Version: 0.19.0 GitCommit: de40ad0docker info
Additional Info
As a possible fix, I'm assuming have a default empty value for the
authConfigwould suffice.