Avoid passing --plain-http when --insecure is specified

[qweeah]

When using ORAS to access plain-HTTP registry service, users need to specify --plain-http. ORAS CLI should be able to do automatic https-to-http handling via specifying --insecure. Similar user experience is already provided common registry clients like Docker CLI, skopeo and nerdctl.

The ultimate goal is to remove --plain-http flag to reduce the number of flags used by ORAS. However, there are some edge cases when the registry has DNS rules configured using the ORAS flag --resolve. This doc outlines the edge cases and provides options for open discussion.

We would like to hear from the community to find an appropriate choice from the given options. All comments are highly appreciated.

P.S. The proposed change is breaking and won't be introduced before CLI v2 release.

[sabre1041]

There is a difference between insecure and plain-http. The former denotes that there is transport via https, but certificate verification is ignored. The latter assumes that transport is occurring via non encrypted means (http)

[TerryHowe]

That is true, plain-http is a lot less secure that insecure.

[sajayantony]

Similar issue - notaryproject/notation#623

I do like the fact of being able to use the secure transport and --insecure-skip-tls-verify
This explicitly calls out that this is the an insecure option.

The main issue I see here is that the flag could do with a rename or --insecure might mean that its a combination of both transport and tls

--insecure-http and --insecure-skip-tls-verify and for usability we could provide one flag --insecure.

Either way my main point here is to ensure that we have some consistency between 2 very similar and aligned tools.

@sabre1041 Do you know if helm allows http for this flag or is it only skipping TLS verification- https://github.com/helm/helm/blob/main/cmd/helm/registry_login.go#L77

[qweeah]

--insecure-http and --insecure-skip-tls-verify and for usability we could provide one flag --insecure.

In this case would it be better to provide one flag with different values like --insecure http|skip-tls-verify rather than having two flags? Since it's unnecessary to specify --insecure-http and --insecure-skip-tls-verify at the same time.

[qweeah]

Indeed, there is a difference between insecure and plain-http, but is it necessary to expose it to the user?

If we iterate every possible value of those two flags, we can get four combinations:

1. --plain-http false --insecure false: establishes HTTPS connections and do cert verification
2. --plain-http false --insecure true: establishes HTTPS connections and skip cert verification
3. --plain-http true --insecure false: establishes HTTP connections and do cert verification (invalid case)
4. --plain-http true --insecure true: establishes HTTP connections and skip cert verification

Case 3 is invalid because you cannot do cert verification when no TLS connect established, which means when --plain-http set to true, then --insecure must be true.

So, it's possible to combine those 2 flags into one and following below workflow when --insecure is set:

• try using HTTPS.
  • If HTTPS is available but the certificate is invalid, ignore the error about the certificate.
  • If HTTPS is not available, fall back to HTTP.

[TerryHowe]

% crane --help | grep insecure
      --insecure                           Allow image references to be fetched without TLS

[qweeah]

Yes, crane also does the HTTPS to HTTP fallback automatically.

[qweeah]

even if --insecure is not set

Update sorry I was wrong. crane also does HTTP-to-HTTP auto fallback with --insecure supplied, but it's not in the doc.

[qweeah]

Below was discussed in today community meeting. See detail in the meeting records.

• Discussed flags regarding insecure experience in ORAS CLI, below options discussed
  • option 1: keep --plain-http and make insecure flag more specific about tls checking, like --insecure-skip-tls
  • option 2: remove --plain-http and make --insecure handles HTTPS-to-HTTP fallback automatically
• Opion 2 introduces breaking changes into CLI so if we are going to introduce it in 1.X release, there are below options
  • option 2.1: keep --plain-http, make flag --insecure which covers both HTTP and HTTPS cases with auto fallback (this also introduces breaking change)
  • option 2.2: make no change to existing flags, add a new flag --insecure-registry which covers both HTTP and HTTPS cases with auto fallback (this is not optimal since extra flags are introduced)
  • option 2.3: wait for 2.0 release to remove --plain-http and make --insecure handles both HTTP and HTTPS cases with auto fallback

[toddysm]

I think we are concentrating on the wrong thing. In what scenario will the user be interested whether it is plain HTTP or not secure TLS? In both cases the communication channel should not be trusted. Both, plain-http and untrusted TLS are testing scenarios only. Cluttering the UI with multiple flags is not necessary IMHO.

[SteveLasker]

@toddysm, I agree in minimizing the number of options and flags. Iin IOT scenarios didn't you find users needed HTTP, as they were running in secured networks?
What are you suggesting?