Incorrect parsing of image URL provided in the command line

[joaopapereira]

What steps did you take: Try to pull a bundle while providing the protocol (e.g. https://, http://) as part URL fails with a strange error

What happened:

imgpkg pull -b https://index.docker.io/k8slt/demo-repo@sha256:aef6d96cde8e41fbdd67202106c89a5c55bd0cd47398de619a60a4ae06a3e388  -o /tmp/lol
Error: Checking if image is bundle: Collecting images: Working with https://index.docker.io/k8slt/demo-repo@sha256:aef6d96cde8e41fbdd67202106c89a5c55bd0cd47398de619a60a4ae06a3e388: Get "https://https/v2/": dial tcp: lookup https on 10.21.82.100:53: no such host

What did you expect: The bundle to be pulled. If you execute without the protocol is works

imgpkg pull -b https://index.docker.io/k8slt/demo-repo@sha256:aef6d96cde8e41fbdd67202106c89a5c55bd0cd47398de619a60a4ae06a3e388  -o /tmp/lol
Pulling bundle 'index.docker.io/k8slt/demo-repo@sha256:aef6d96cde8e41fbdd67202106c89a5c55bd0cd47398de619a60a4ae06a3e388'
  Extracting layer 'sha256:34de6e22982f89d95517c1cdb76e4d81f6a0735c78f89c56ab7a627b785b0aad' (1/1)

Locating image lock file images...
One or more images not found in bundle repo; skipping lock file update

Succeeded

Anything else you would like to add: [Additional information that will assist in solving the issue.]

Environment:

• imgpkg version (use imgpkg --version): 0.8.0
• Docker registry used (e.g. Docker HUB): docker hub, but is unrelated
• OS (e.g. from /etc/os-release): MacOS

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help to work on this issue.

[aaronshurley]

I think we can consider this issue carvel-accepted because we have an undesirable result at the moment by having an unhelpful error message. However, we have a few potential solutions that we could considder so that we can agree on a way forward. A couple of options that come to mind:

1. Return a helpful error message if a protocol is included. This may not be ideal UX but is consistent and prevents surprises.
2. Always strip the protocol. By default, imgpkg uses "https". This could create a surprising result if someone uses "http" and it gets converted to "https".
3. "Intelligently" strip the protocol. This option could essentially apply InsecureSkipVerify: false when "https" is used (default behavior) and InsecureSkipVerify: true when "http" is used. This would be the most complex implementation and maybe the "friendliest" UX.

Any other options that we should consider? Any option that is most preferred?

cc @joaopapereira @cppforlife @pivotaljohn @DennisDenuto

[gcheadle-vmware]

I was able to reproduce using binary built from current develop state: https://github.com/vmware-tanzu/carvel-imgpkg/commit/f5f0bf61e92fd4a44a3a13e4a6f7f58b2848c1fc

Personally, I feel like making assumptions about a users intent when using http or https would be providing another way to specify the --registry-insecure flag. Since we already have the flag, that approach feels confusing for the user.

I'm +1 for "Always strip the protocol", and I think that if http is given, we could give a warning saying that we wont check the http connection unless the --registry-insecure flag is set.

[joaopapereira]

I believe that imgpkg should always use https to talk to the registry, unless the --registry-insecure flag is present or the user tell imgpkg to use a different protocol. Given that I believe that internally imgpkg should always remove the protocol from the provided url.

Special cases:

1. The users provided the url https://testing.reg.io and --registry-insecure flag we should error out with a message that looks something like "The provided URL 'https://testing.reg.io/image' uses a secure connection to the registry but the flag '--registry-insecure' was also provided. (hint: For insecure connection: Remove the protocol from the URL or adjust it to 'http'. For secure connections remove the flag '--registry-insecure' from your invocation.)"
2. The user provided the url http://testing.reg.io and no flag. imgpkg can warn the user that an insecure connection will be used for the transport.

Also we should consider the fact that the following case is also possible: imgpkg copy -b http://some.reg.io/image --to-repo https://some-other.reg.io and imgpkg should be able to do both an insecure and secure connection to the different registries

[gcheadle-vmware]

I think that Joao's comment outlines the context needed to fix this bug. Moving issue to "Unprioritized Backlog" column.

[aaronshurley]

Labeled this as unprioritized-backlog and changed it to an enhancement as it feels like additional functionality. #214 has already made a nudge in an improved direction by providing a better error message. Leaving this story as is to focus on potentially automating this parsing.