Can you just confirm with the devs that this change was intentional and they haven't been hacked?

Sure, we'll see if they respond to this python-pillow/Pillow#3199

They responded with an explanation stating that it shouldn't have changed. Well, maybe I've been testing a hacked archive then. I'll try to find out what's going on.

@s-sajid-ali Can you comment on this? I'm not so sure the checksum for this was initially correct for 5.1.0 if the file wasn't able to change on the pypi.io site.

I'm getting cee9bc75bff455d317b6947081df0824a8f118de2786dc3d74a3503fd631f4ef for the downloaded archive for 5.1.0 from spack with this PR, which is the same as what is listed on the pypi pillow site and confirmed in the linked issue I posted on their github. I'm confident the correct checksum is in this PR, but just confused about where the original one came from.

I might have made a mistake then. Apologies for the incorrect checksum .

I find it hard to believe that no one else noticed that the py-pillow checksum was wrong for a whole month, but who knows. I did know that PyPI doesn't let you reupload, so there's no way for a checksum to change. @s-sajid-ali can you check your Spack downloads cache to see if the tarball is still lying around? If I had to guess, maybe you manually downloaded and added the checksum for the .zip instead of the .tar.gz.

I can also do a diff of the last two versions just to make sure there are no viruses in there 😛

Could be. I've removed the file during a spack clean (maybe -a)sometime I guess.

Mystery solved. The checksum that was in the package is the checksum from the GitHub tarball, not the PyPI tarball.

Will keep this in mind next time.

Yeah, so when you upload tarballs to PyPI, it only uploads the bare minimum of files necessary to install the package, not unit tests or travis/flake8/git config files. That's why the checksums never match.