Credential Helper URL scheme mismatches

[tigris]

Description

When using docker login with a [SERVER] argument that is a fully qualified URL, it bypasses the credential helpers.

Steps to reproduce the issue:

1. Configure the ECR Credential helper
2. Attempt to login using docker login ... ${ACCOUNT_ID}.dkr.ecr.ap-southeast-2.amazonaws.com and notice that there is an error message around the credential helper not supporting store. (This is expected).
3. Attempt to login using the above method but add https:// to the front of the [SERVER] URL. Notice that this will bypass the credential helper and login, storing the credentials in the normal CredStore you have configured.
4. Update your credential helper config so that there is an entry for both the URL with and without a scheme.

{
	"auths": {
	},
	"credHelpers": {
		"${ACCOUNT_ID}.dkr.ecr.ap-southeast-2.amazonaws.com": "ecr-login",
		"https://${ACCOUNT_ID}.dkr.ecr.ap-southeast-2.amazonaws.com": "ecr-login"
	}
}

It's actually non-obvious to me what the default scheme for [SERVER] is if I do not provide one to docker login. As an example, the output from aws ecr get-login in older versions of aws-cli version 1, would output a command for your shell to evaluate, where the URL was using the https scheme. In which case, the correct way to use aws-cli would be bypassing the credential helper probably accidentally. That "bug" may well be the aws-cli v1 behaving incorrectly by providing a HTTPS URL, I can't tell.

As a reference docker pull ${ACCOUNT_ID}.dkr.ecr.ap-southeast-2.amazonaws.com/my-image doesn't allow a scheme, it returns invalid reference format if you try and add one.

Describe the results you received:

When doing a docker login, a credential helper will only be used if the [SERVER] matches the entry on credHelpers EXACTLY. Even though when you use docker login without a scheme attached, it seemingly defaults to https.

Describe the results you expected:

If I configure a credential helper in credHelpers without a scheme, then I expect it to be used no matter what scheme I use on the docker login option.

Since I can't specific a scheme on docker pull or docker run image references, it would seem the only URL worth putting in credHelpers is a URL without a scheme. As such, doing a docker login with a scheme of any kind will never match a credential helper. I think docker login should either not accept a scheme for [SERVER] at all, the same way docker pull can not. Or when matching against a credential helper, it should ignore the scheme.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client: Docker Engine - Community
 Version:           20.10.16
 API version:       1.41
 Go version:        go1.18.2
 Git commit:        aa7e414fdc
 Built:             Wed May 11 16:22:17 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.6.1 (76265)
 Engine:
  Version:          20.10.13
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.15
  Git commit:       906f57f
  Built:            Thu Mar 10 14:05:37 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.5.10
  GitCommit:        2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc:
  Version:          1.0.3
  GitCommit:        v1.0.3-0-gf46b6ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.1)
  compose: Docker Compose (Docker Inc., v2.3.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 210
 Server Version: 20.10.13
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2a1d4dbdb2a1030dc5b01e96fb110a9d9f150ecc
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 6
 Total Memory: 7.765GiB
 Name: docker-desktop
 ID: HKCM:S5QQ:6K5Z:BBAB:SUBT:CJCQ:736Q:ZZRP:5P64:TV3S:4FIE:43VZ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):