zarf tools registry ls <img> --full-ref has strange port in output

[btlghrants]

Environment

Device and OS: HP ZBook Fury 17 G7 Mobile Workstation / Ubuntu 20.04.6 LTS
App version: Zarf v0.29.2
Kubernetes distro being used: k3d version v5.6.0 / k3s version v1.27.4-k3s1
Other:

Steps to reproduce

1. Run zarf tools registry ls <img> with the --full-ref flag multiple times.

Expected result

I expect the returned images' registry port to reflect the one I passed in.

Actual Result

I see a rando registry port output with my result. And the port seems to change every time I call..?

Visual Proof (screenshots, videos, text, etc)

$ zarf tools registry ls 127.0.0.1:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
127.0.0.1:41117/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
127.0.0.1:41117/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

$ zarf tools registry ls 127.0.0.1:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
127.0.0.1:42923/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
127.0.0.1:42923/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

$ zarf tools registry ls 127.0.0.1:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
127.0.0.1:42461/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
127.0.0.1:42461/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

Severity/Priority

Low/Low

Additional Context

It's my first bug report to this project... so if I did a dumb, be sure to let me know. Many thanks & keep up the good work!

[cmwylie19]

definitely looks suspicious to me too @btlghrants . This seems to be an issue in the upstream crane package

https://github.com/defenseunicorns/zarf/blob/3c6c74bd3fdd4469fb9ac3e554fc55efb529d8d4/src/cmd/tools/crane.go#L44

[Racer159]

This is actually due to our wrapping logic. if we detect the repository matches the repo in Zarf state we will open a tunnel (on a random open port) to connect and get the information back - on most commands that doesn't affect the output but here it does - we could look to see if 1) we can modify the headers to tell the registry that there is a proxy in the way and it should act as the original address or 2) mutate the response to contain the correct host/port if we are using a tunnel.

[blancharda]

on most commands that doesn't affect the output but here it does

I believe this also impacts zarf tools registry catalog --full-ref (and probably any command which uses an automatic port-forward). Catalog appears to display the random local port-forwarded port rather than the proper ref to the node port:

~ zarf tools registry catalog --full-ref

 NOTE  Retrieving registry information from Zarf state

 NOTE  Opening a tunnel from 127.0.0.1:49658 locally to 127.0.0.1:31999 in the cluster
127.0.0.1:49658/bitnami/redis
127.0.0.1:49658/defenseunicorns/uds/identity-config
127.0.0.1:49658/defenseunicorns/zarf/agent
127.0.0.1:49658/gitea/gitea
...

This can then impact subsequent commands. For example, if I check the catalog for a ref, and then try to pull the tags with zarf tools registry ls 127.0.0.1:49658/bitnami/redis -- the automatic port-forward isn't triggered, and it hits an (expected) connection refused error:

Error: reading tags for 127.0.0.1:49658/bitnami/redis: Get "https://127.0.0.1:49658/v2/": dial tcp 127.0.0.1:49658: connect: connection refused; Get "http://127.0.0.1:49658/v2/": dial tcp 127.0.0.1:49658: connect: connection refused