xoofx/UnityNuGet

Integrity checksum fails on many packages (Fork hosted on Azure)

loopervfx opened this issue · 3 comments

Hi, we forked your repo and have only changed the registry.json to add some packages and be able to manage it on our own for dev ops and developers. We are hosting on Azure as a web "App Service" with an azurewebsites.net subdomain. The setup is as close to yours as possible, though perhaps overprovisioned with a Premium0V3 (P0v3) App Service Plan host to keep iteration time low and avoid any issues with resources while configuring and testing the deployment. There are no cpu, memory or storage usage issues on the server.

For some reason when adding most packages, the sha1 hash integrity checksum fails. Do you have any idea why this would occur or can you provide some best practices here? Thank you very much and we are happy to share any upstream improvements or fixes in the future to help keep this project going.

[Package Manager Window] Error adding package: org.nuget.system.buffers@4.5.1. sha1-2XSC2tY6ZxBTefLYyp/+n6SnwSI= integrity checksum failed when using sha1: wanted sha1-2XSC2tY6ZxBTefLYyp/+n6SnwSI= but got sha1-l+iiE/llTFbhXkOA8CnRE3St1oQ=. (14496 bytes) UnityEditor.EditorApplication:Internal_CallUpdateFunctions ()

image image

Okay, so:

  • Most of packages that install successfully tend to have very few dependencies, and they are not some core package in the System namespace.
  • Most of the packages that fail, are either some core package such as those in the System namespace (But not all) or they have a dependency on a core package such as those in System.

I also don't see anything in the docker or application logs of any relevance, but I can post them if that helps, or if there is somewhere else i can be looking for or doing for more verbose logging, please let me know.

image

I also found this issue from a few years ago, that mentions sha1 files not previously written. Not the same issue as the registry.json appears to be fine but the sha1 files seem to be mismatched. Could the sha1 files be possibly stale (but match) on your azure app service instance, not overwritten, creating a false positive integrity check?

One thing @xoofx, I don't know if it's just tests you've been doing but I see that now it doesn't serve all the packages of "registry.json"?

Yes, it was a mishandling when a sha1 file was not previously written, it would error and stop processing. I have pushed a fix.

_Originally posted by @xoofx in #27 (comment)

"org.nuget.system.buffers"
"org.nuget.system.memory"
"org.nuget.system.numerics.vectors"
"org.nuget.system.threading.tasks.extensions"
"org.nuget.system.runtime.compilerservices.unsafe"

Also curious that the "core" packages that are causing the most issues as dependencies (above) happen to also be in this short list provided by the issue reporter:

#27 (comment)

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the Stale label or comment on the issue.