@Dan_Woolf I can confirm that it works when we use an admin user access key. Thanks! It's a workaround, I suppose, but it's of course not optimal to give proget such wide permissions to the registry. Scope mapped tokens will be supported in a future version of proget, I hope?

@Dan_Woolf It does look OK on our end, I've tried the following:

$ read -s pw
[pasted the token I sent you]
$ echo $pw | docker login -u tokenname --password-stdin registryname.azurecr.io
WARNING! Your password will be stored unencrypted in /home/x/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
$

I was then able to pull images from the registry.

@Dan_Woolf Thank you, I have now sent an email as suggested.

@atripp That's not so easy, I'm afraid. It would take a while to get someone to change the firewall config for me, and it sort of goes against the policy here anyway.

I might try to setup a proget instance on my laptop instead, just to test. But it does seem like a pretty long shot, the post you're referring to is talking about a different type of proxy. Also, as squid is tunnelling TLS traffic in our case (on both sides), I don't think it would be able to screw with the contents of HTTP headers tbh.

Is it by the way possible to disable the proxy for only the one connector or feed, isn't that a global setting?

@Dan_Woolf Thanks for the info!

We're using a private Azure registry, and I've tried multiple repositories.

Fiddling around with az acr manifest list I'm pretty sure I've ascertained that all of the images use the same format, application/vnd.docker.container.image.v1+json.

We're using a squid proxy both between the clients and the proget server, and between the proget server and the Internet. Nothing in the squid logs indicate that they interfere with the traffic.

For authentication, we're using a scope mapped token with the scope _repositories_pull, and I've verified that I'm able to login with such a token using podman login and podman image pull.

@Dan_Woolf yes, it seems like that did the trick, thanks. :)

Looking at the other sources we use, which include quay.io, public.ecr.aws, ghcr.io, registry.k8s.io and our own registry in Azure (which requires authentication), I got all of them working except our Azure registry. It also seems important to keep the "Attempt to search the container registry" checkbox cleared, by the way.

It looks like the "not found: manifest unknown: manifest unknown" error message will display no matter the reason for the failure, which might include wrong endpoint setting, the "Attempt to search..." being checked, registry redirects not being allowed through the proxy or maybe also authentication errors?

I wish I'd get some more detailed information on connector errors, as it's hard to get the Azure registry working as it is now.

@Dan_Woolf Thanks, here is the connector setup:

There are no cached images.

@stevedennis we've tried upgrading to 2023.8, as there is a relevant-ish fix in there (https://inedo.myjetbrains.com/youtrack/issue/PG-2388), but unfortunately, there was no change in the behavior.

@stevedennis we've upgraded ProGet multiple times, so it's a bit tricky to be sure in which version this stopped working. Looking at the published dates of the working container images, however, it might very well be when we upgraded from 2022.0.28 to 2023.0.3. We're using amd64 only, and the problem occurs also with our own images, which aren't multi-platform.