Digging more into this, it appears that "pip search" is basically unsupported at this point, even by pypi.org. You can disregard this issue.

My understand is that /simple is the endpoint for package retrieval and /pypi is for searching. Regardless, neither works.

This happens both with empty and non-empty feeds.

When attempting to search a feed using "pip search", I receive the following error:

An error occurred processing a POST request to http://<redacted>/pypi/maglabs/pypi: Root element is missing.

System.Xml.XmlException: Root element is missing.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
at System.Xml.Linq.XDocument.Load(Stream stream, LoadOptions options)
at Inedo.ProGet.WebApplication.FeedEndpoints.Pypi.XmlRpcHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, PypiFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E359832\Src\ProGet.WebApplication\FeedEndpoints\Pypi\XmlRpcHandler.cs:line 18
at Inedo.ProGet.WebApplication.FeedEndpoints.Pypi.PypiHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, PypiFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E359832\Src\ProGet.WebApplication\FeedEndpoints\Pypi\PypiHandler.cs:line 35
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E359832\Src\ProGet.WebApplication\FeedEndpoints\FeedEndpointHandler.cs:line 188

There's nothing in the diagnostic logs beyond "Object reference not set to an instance of an object."

As a workaround I set the account and containers to public but limited access via a private endpoint. Not ideal, but better than nothing.

Now I'm able to push the docker layers, but after they are pushed, I receive a 500 Internal Server Error from the server. The logs show:

A 500 error occurred in docker: Object reference not set to an instance of an object.
A 500 error occurred in docker: Object reference not set to an instance of an object.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
Request finished HTTP/1.1 PUT http://<redacted>/v2/docker/busybox/manifests/latest application/vnd.docker.distribution.manifest.v2+json 527 - 500 109 application/json 21769.4992ms

I think I know the problem.

My guess is that you're performing the copy operation specifying the normal URI of the source blob, which is the public URI. Instead, you need to use the Shared Access Signature (SAS) URI. This can be obtained via the GenerateSasUri method on the BlobClient.

I created a brand new storage account, copied over the connection string, and still receive the same errors.

Looking at the http traffic, it's able to upload the blob without issue but is failing when it's trying to copy the uploaded blob to it's final destination.

Setting the account and containers to public is not an option.

Hello,

Upon upgrading to 2022 I can no longer push docker images when using Azure Blob storage.

At first I received these errors:

A 500 error occurred in docker: Public access is not permitted on this storage account.
RequestId:6d0b5687-601e-0062-2695-9c1193000000
Time:2022-07-21T00:04:04.4475288Z
Status: 409 (Public access is not permitted on this storage account.)
ErrorCode: CannotVerifyCopySource
Content:
<?xml version="1.0" encoding="utf-8"?><Error><Code>CannotVerifyCopySource</Code><Message>Public access is not permitted on this storage account.
RequestId:6d0b5687-601e-0062-2695-9c1193000000
Time:2022-07-21T00:04:04.4475288Z</Message></Error>
Headers:
Server: Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
x-ms-request-id: 6d0b5687-601e-0062-2695-9c1193000000
x-ms-client-request-id: f079cd5b-6216-4469-a1c8-45c59f7ff124
x-ms-version: 2021-06-08
x-ms-error-code: CannotVerifyCopySource
Date: Thu, 21 Jul 2022 00:04:04 GMT
Content-Length: 246
Content-Type: application/xml

While I shouldn't need to enable public access, for testing purposes I did. After doing so, I started receiving this error:

A 500 error occurred in docker: Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:f3d12d81-001e-0006-219f-9ce00b000000
Time:2022-07-21T01:13:15.7594171Z
Status: 401 (Server failed to authenticate the request. Please refer to the information in the www-authenticate header.)
ErrorCode: CannotVerifyCopySource
Content:
<?xml version="1.0" encoding="utf-8"?><Error><Code>CannotVerifyCopySource</Code><Message>Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:f3d12d81-001e-0006-219f-9ce00b000000
Time:2022-07-21T01:13:15.7594171Z</Message></Error>
Headers:
Server: Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
x-ms-request-id: f3d12d81-001e-0006-219f-9ce00b000000
x-ms-client-request-id: 0e5467a9-7e39-42ec-93da-53b037e6ad7f
x-ms-version: 2021-06-08
x-ms-error-code: CannotVerifyCopySource
Date: Thu, 21 Jul 2022 01:13:15 GMT
Content-Length: 297
Content-Type: application/xml

The connection string I entered contains the access key so there should be no reason it can't authenticate. This also worked fine before I upgraded.

As it is I can no longer push docker images, so any assistance you could provide would be greatly appreciated.

Thank you,
Brett

@Dan_Woolf Excellent. Thank you for your assistance with this!

@Dan_Woolf Adding library/ to the image name also doesn't work.

Hi @Dan_Woolf,

It looks like it works if there is a prefix on the repository name, but doesn't work if there isn't. I've tried setting the "Do not use library/ prefix for repositories without namespaces (this may be required for some container registries like Microsoft Container Registry)" option on the connector but it makes no difference.

Thanks,
Brett

Hi Dan,

• I'm running ProGet 6.0.6
• It only includes Docker images
• It does not include Helm packages

Thanks,
Brett

Hello,

Does anyone have a docker connector successfully working against azurecr.io? (Azure Container Registry)

No matter what I try, I just get a "manifest unknown" error back from ProGet. Even if I intentionally change the connector username or password to something that should fail, I still just get the same error. There is nothing useful in the logs, so I'm at a loss.

Thanks

I'm not sure exactly when it started failing.

I know the PAT is good, as I can use it outside of ProGet without issue.

I don't doubt that the changes may be on the GitHub side of things. Are you able to connect to ghcr in your environment?

I'm happy to help however I can. Is there a way to get more verbose logging? I can also run any test releases you want to publish.

I can't pull or search images either. No errors in the Diagnostic center.

Hello,

I have a docker connector to ghcr.io (the github container registry) which authenticates with a personal access token. This used to work just fine, but recently stopped. I can authenticate directly to ghcr.io from the command line with the same username and password, but I can now no longer connect and the ConnectorHealthCheckRunner reports a 403 error.

Connector ghcr health check reported error: The remote server returned an error: (403) Forbidden.

Nothing on my end has changed, it just stopped working.

Any ideas?

Thanks,
Brett Polivka

UPDATE: Cargo Feeds are Available!

Cargo (Rust) Feeds are available as of ProGet 2024.20.

---

Here is the original message

If it's not already on the roadmap, it would be wonderful if support for Rust Cargo packages could be added.

The language is quickly gaining in popularity and I would love to be able to use ProGet to host private packages.

Thanks. I get that things get deprecated and libraries need to be upgraded, but you guys really need to do a better job of regression testing your changes. I seem to be tripping over these regressions on a pretty regular basis lately. As it is now, I'm dead in the water until this next fix gets published.

Feels like every release fixes one Azure Blob problem and creates another.