[Bug]: Docker auth config env variable format mismatch with Docker CLI

[fedorkanin]

Testcontainers version

v0.39.0

Using the latest Testcontainers version?

Yes

Host OS

MacOS

Host arch

ARM

Go version

1.25

Docker version

28.3.2

Docker info

Client:
 Version:    28.3.2
 Context:    desktop-linux
Server:
 Server Version: 28.3.2

What happened?

Docker CLI and testcontainers-go expect different formats of DOCKER_AUTH_CONFIG env variable, which seems unintended and misleading. The same DOCKER_AUTH_CONFIG that works with Docker CLI fails with testcontainers-go, and vice versa. It leads to auth problems that are hard to debug, taking into account there is little documentation on this env variable on both sides.

I've written a repro repository so there is a way to verify this issue.

Particular formats description

• Docker CLI only accepts base64-encoded "auth" field inside the "registry". See code and pull request. All other fields are disallowed and will result in an error. Example:

  {
    "auths": {
      "registry": {
        "auth": "base64(username:password)"
      }
    }
  }

  The base64-encoded "auth" is then parsed into "username" and "password" fields internally.

• testcontainers-go expects "username" and "password" fields, it unmarshals DOCKER_AUTH_CONFIG directly into dockercfg.Config, see code. Example:

  {
    "auths": {
      "registry": {
        "username": "user",
        "password": "pass"
      }
    }
  }

  It supports "auth" field, but does not parse it into "username" and "password", so Docker login fails with just "auth" field.

Relevant log output

Additional information

No response

[yashgoyal0110]

Hey @fedorkanin
May I work on this one?

[fedorkanin]

@yashgoyal0110 sure, contact me if you'll need any extra info. Thanks!

[yashgoyal0110]

@yashgoyal0110 sure, contact me if you'll need any extra info. Thanks!

Thanks!
Can you please assign it.

[fedorkanin]

I'm not the project's maintainer so I can't do this, I guess @mdelapenya can help with it :)

[mdelapenya]

@fedorkanin @yashgoyal0110 given that we can talk directly to the CLI maintainers, I'm researching internally before proposing any solution. Will update this issue once we come to a plan.

Thanks for the report!