Enable configuring a certificate authority file for registry client.

[absoludity]

Just as Helm allows as --kube-ca-file option to use a specific certificate authority file for the Kubernetes API Server connection, it would be great if ORAS enabled requests to the registry to be made with a specific certificate authority, so that connections to internal private registries are not susceptible to machine-in-the-middle.

Currently it appears the only option is to use the --insecure flag which I assume results in a TLS connection configured with InsecureSkipVerify. As per the docs there "This should be used only for testing or in combination with VerifyConnection or VerifyPeerCertificate".

[souleb]

Hi,

I would like to work on this issue if possible.

Regards,
Soule

[sajayantony]

Should we target using oras-go v2?

[sabre1041]

@sajayantony I would recommend it be part of v1 and v2 since it is a capability that would be desired by consumers of each version

[scottrigby]

👍 should be fixed in v2 first, then would need a backport to v1 for Helm users to take advantage.

PS, when there is a plan for the oras-project/oras-go stable v2.0.0 release, we should coordinate to also plan the Oras dependency upgrade in Helm.

[scottrigby]

👍 should be fixed in v2 first, then would need a backport to v1 for Helm users to take advantage.

PS, when there is a plan for the oras-project/oras-go stable v2.0.0 release, we should coordinate to also plan the Oras dependency upgrade in Helm.

Update to this note. I was not aware that v2 has removed docker auth and implemented their own auth. Because of this v2 would have to implement things from scratch that v1 could do more easily using Docker client auth. So we may need to propose a working change for v1 to start which would then need to be ported to v2 (not backported from v2 to v1). V1 is needed for Helm at this point.

However, to keep with our agreement to ensure v1 and v2 have the opportunity to stay in sync in terms of features, we should in that same proposal give a recommendation on how the new v2 auth would want to implement the same thing. This way, we can get signoff from the v2 maintainers before approving/merging into v1. So we at least stay on the same page with features even if the code is completely different.

@sajayantony does this make sense to you?