Describe the bug

The crane.Pull behavior appears to be inconsistent with the CLI when attempting to reach either a registry using HTTP, or a registry that uses HTTPS but with a self-signed certificate.

The crane CLI accepts the --insecure flag which seems to support either case transparently. To accomplish this with the library, you'd have to pass both the crane.Insecure[1] option and crane.WithTransport[2] to get the same behavior as observed in the crane CLI's code.

[1] https://github.com/google/go-containerregistry/blob/main/cmd/crane/cmd/root.go#L59
[2] https://github.com/google/go-containerregistry/blob/main/cmd/crane/cmd/root.go#L75-L78

To Reproduce

I just used caddy to throw up a quick reverse-proxy with "internal" certs, and modified my host file to point the --from domain to my own machine. Then targeted existing images from the origin registry.

caddy reverse-proxy --to https://quay.io --internal-certs --from https://registry.example.com:8443

A code snippet like the following works as I expect.

        // copied from crane's CLI
	rt := remote.DefaultTransport.(*http.Transport).Clone()
	rt.TLSClientConfig = &tls.Config{
		InsecureSkipVerify: true, //nolint: gosec
	}

	img, err := crane.Pull("registry.example.com:8443/fedora/fedora:38", crane.Insecure, crane.WithTransport(rt))
	if err != nil {
		panic(err)
	}
	fmt.Println(img.Layers())

If you pull out the Transport definition, it throws an error that I believe indicated that the client sent an HTTP request to an HTTPS server.

Expected behavior

I expected the Insecure flag to crane to behave like the CLI, in that the self-signed certificate is ignored when pulling the image, and the image downloads as expected. To that end, I would imagine that passing crane.Insecure would also set the crane.WithTransport option similar to how the CLI does it, or that the Pull logic would handle the transport definition internally using the insecure option's value as an input (if no transport option was passed in).

With the same reverse-proxy setup described above, you should be able to crane pull --insecure registry.example.com:8443/fedora/fedora:38 fedora38.tgz and have it succeed.

Additional context

I noticed that there's a Scheme handler https://github.com/google/go-containerregistry/blob/main/pkg/name/registry.go#L75 - Just looking at that, I'm actually unsure exactly what scheme is being used in cases where both crane.Insecure and crane.WithTransport are passed. I'm not sure if I'm missing something, or this particular block that derives the scheme is out of scope, but it seemed odd that a case where both options were passed seems to behave correctly. I would have thought for sure that we'd still be getting http given what I'm seeing there.

• Version of the module: v0.13.0
• Registry used (e.g., GCR, ECR, Quay): n/a