TARBALL_INTEGRITY failing when installing package spdx-correct

[sriharshachilakapati]

I'm getting this message when trying to install the spdx-correct package.

WARN  GET https://registry.npmjs.org/spdx-correct/-/spdx-correct-3.1.1.tgz error (ERR_PNPM_TARBALL_INTEGRITY). Will retry in 10 seconds. 2 retries left.
 ERROR  Got unexpected checksum for "https://registry.npmjs.org/spdx-correct/-/spdx-correct-3.1.1.tgz". Wanted "sha512-lr2EZCctC2BNR7j7WzJ2FpDznxky1sjfxvvYEyzxNyb6lZXHODmEoJeFu4JupYlkfha1KZpJyoqiJ7pgA1qq8Q==". Got "sha512-cOYcUWwhCuHCXi49RhFRCyJEK3iPj1Ziz9DpViV3tbZOwXD49QzIN3MpOLJNxh2qwq2lJJZaKMVw9qNi4jTC0w==".

I'm on macOS Big Sur, and node version is 14.16.0 LTS. Using latest PNPM.

I also raised this at the package's repository at jslicense/spdx-correct.js#35 but the author things this is an issue of PNPM and not of spdx-correct.

Weirdly, it is working with NPM though, no warnings or errors. Any idea what is going wrong?

[zkochan]

This checksum is the checksum of the 3.1.0 version of spdx-correct:
sha512-lr2EZCctC2BNR7j7WzJ2FpDznxky1sjfxvvYEyzxNyb6lZXHODmEoJeFu4JupYlkfha1KZpJyoqiJ7pgA1qq8Q==

I don't understand why your lockfile has it for the 3.1.1 version. Was there a merge conflict in the lockfile that was resolved incorrectly?

[sriharshachilakapati]

Sorry, I missed the notification. Merge conflict is not an issue, since this is the first time I am updating the repo to use PNPM. We were using NPM previously. Could it happen for any odd reason where importing of existing lockfile fails?

[zkochan]

Were you using the `pnpm import` command? Sri Harsha Chilakapati <notifications@github.com> ezt írta (időpont: 2021. febr. 27., Szo 15:51):

…

Sorry, I missed the notification. Merge conflict is not an issue, since this is the first time I am updating the repo to use PNPM. We were using NPM previously. Could it happen for any odd reason where importing of existing lockfile fails? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOWTG7VKJWIUXAEQERDBRTTBD2G3ANCNFSM4YC64NDA> .

[sriharshachilakapati]

No, I was just trying to do pnpm i after deleting the node_modules directory. Let me try deleting the lock file too. I'll get back on Monday. This is happening in work system.

[delanni]

We've been experiencing similar symptoms in our big monorepo.

The case is that sometimes after a package version update, PNPM seems to resolve a package from the local ~/.pnpm-store cache, with a tarball: resolution.

@sriharshachilakapati - check your pnpm-lock.yaml, find the package that's failing for you, and check if you see a tarball: entry pointing to some file. If so, the case is similar to ours. To work around, I suggest these three steps:
1 - remove the yaml entry for the dependency (probably from the line that start with spdx-correct/3.1.1:)
2 - remove the local install cache (usually its ~/.pnpm-store/)
3 - reinstall your everything, and hope pnpm will resolve the correct version with the correct hash.

@zkochan - I can't really come up with a reproduction case for this one, because it happens transiently, and when it happens, it's already too late. But what we've seen, is that sometimes, after updating a package version, the pnpm-lock.yaml will contain the new version's entry, with a tarball: resolution pointing to a file that has the new version in the package's name, however, the integrity hash contains the hash for the old version.

Local installs will succeed (however, installing the old package contents AS IF it was the new package fairly dangerous) and remote installs will break with the same errors like above, because the remote would actually download the new version's bundle, and fail because the integrity actually checks for the old version.

Do you have any leads on the topic, why this could happen, or how we could support investigation?

[zkochan]

@shellscape in your case (#3137), did your package have the resolution: { tarball: * } entries in the lockfile?

[zkochan]

Were any of you using pnpm install --lockfile-only when this occurred?

[zkochan]

I have found a potential issue: fac8480

But I think it would only break with pnpm install --lockfile-only. I did not try to reproduce it yet.

[delanni]

Yes, we usually use pnpm i --lockfile-only to recover the lockfile.

[zkochan]

I have done a change that might fix the issue, so try and see if it still reproduces with pnpm@5.18.4

[zkochan]

🚢 5.18.5

[Jesperpaulsen]

I'm having a similar issue. The only difference is that for me, both checksums are equal, so don't know why it's failing.

 ERROR  Got unexpected checksum for "https://registry.npmjs.org/source-map-js/-/source-map-js-0.6.2.tgz". Wanted "sha512-/3GptzWzu0+0MBQFrDKzw/DvvMTUORvgY6k6jd/VS6iCR4RDTkWh6v6WPwQoUO8667uQEf9Oe38DxAYWY5F/Ug==". Got "sha512-/3GptzWzu0+0MBQFrDKzw/DvvMTUORvgY6k6jd/VS6iCR4RDTKWH6v6WPwQoUO8667uQEf9Oe38DxAYWY5F/Ug==".

[delanni]

There's are differences between the two. Pay attention to the capital letters and lowercase letters too.

[Jesperpaulsen]

Oh, you are right. My bad!

After updating to the latest version the problem is gone.