Checksums of of 2.2.0.1 and 2.2.1.1 tar balls changed

[ajaust]

I tried to install the bindings 2.2.1.1 today using the py-pyprecice recipe for Spack. However, it failed due to wrong checksums. I checked and indeed the checksums for v2.2.1.1.tar.gz and v2.2.0.1.tar.gz from the GitHub releases page were wrong. I updated the Spack recipe accordingly (https://github.com/spack/spack/pull/24264).

It is puzzling me what went wrong. First, I assumed that I made a mistake when updating the Spack recipe. However, I found the "old" archive v2.2.1.1.tar.gz on my machine which indeed has a different checksum than the current archive.

Checksums:

File	Date	sha256sum
v2.2.1.1.tar.gz	2021-06-04	481715c9e90660d3d97e63ee590a3b74a17564cd5cac3bfceceb59788fd11b14
v2.2.1.1.tar.gz	2021-06-11	d96674f1ff91761c29efce34f8e09e2ec29a4862227b7204439e865dbe755a86

Both files have been downloaded from GitHub.

As I was able to find the old file (from 2021-06-04) I could do a diff on the extracted archive. I found a single difference in the _version.py file:

diff -r python-bindings-2.2.1.1-4817/precice/_version.py python-bindings-2.2.1.1-d966/precice/_version.py
26c26
<     git_refnames = " (HEAD -> develop, tag: v2.2.1.1, master)"
---
>     git_refnames = " (tag: v2.2.1.1, master)"

The questions now are:

• Why did the content of the archive change?
• How did we that the content of the archive change?
• Why did the change go unnotices?
• How do we prevent this from happening again?
• Did the same happen to 2.2.0.1?

[BenjaminRodenberg]

Just had a phonecall with @ajaust. I'll try to summarize my thoughts here:

precice/_version.py is generated by versioneer by using a template provided in the repository. As far as I understand this happens when creating the tar.gz through git archive.

I did a small experiment on my own: I ran git archive --format=tar.gz -o /tmp/python-bindings.tar.gz --prefix=python-bindings/ develop (from here) on my own and got git_refnames = " (origin/develop, origin/HEAD, develop)" in the _version.py of my hand-crafted tar.gz.

Let's try do answer the first question from above:

• Why did the change go unnoticed?

I assume that git executes git archive (probably on the tag that is connected to the release?), when downloading the tar.gz. This means that there is no need to manually update the archive, but this might also happen, if the result of calling git archive differs from before.

As far as I understand git_refnames = " (HEAD -> develop, tag: v2.2.1.1, master)", it just shows which tags, branches etc. point to the commit of the release. This also means that as soon as master or develop do not point to the commit anymore this will get updated when calling git archive.

• Why did the content of the archive change?

The situation that we see here is the following: git_refnames = " (HEAD -> develop, tag: v2.2.1.1, master)" originates from the point in time when master, develop and v2.2.1.1 were pointing to the very same commit. But https://github.com/precice/python-bindings/commit/f3b5761ce3047b56fe5dc294347efaffdee59b73 changed this situation. develop is now ahead of master and v2.2.1.1 that are still pointing to https://github.com/precice/python-bindings/commit/20395574400d6a28da460b273c2ea972a658460d. Therefore, develop disappears from our list git_refnames = " (tag: v2.2.1.1, master)".

• Did the same happen to 2.2.0.1?

Same, but different. I assume that for 2.2.0.1 we see that change that master disappears from the list: git_refnames = " (tag: v2.2.0.1, master)" becomes git_refnames = " (tag: v2.2.0.1)". @ajaust Do you by chance also have the old tar.gz for v2.2.0.1 and could verify this?

• How do we prevent this from happening again?

I assume that this will happen again. v2.2.1.1 currently lists master and this will change with the next release. I would suggest to wait for the next release to verify what I am describing above. As soon as we know that what I'm describing above is actually not just an assumption but true, we should try to find a solution. Some ideas:

1. Configure versioneer to not store references to branches?
2. Push an empty commit to master directly after the release to make sure v2.2.1.1 only point to the tag and not to master or develop (very very dirty solution imho)
3. Contact developers of versioneer. Is this a bug?

[BenjaminRodenberg]

There is already an issue for this problem in the versioneer repository (https://github.com/python-versioneer/python-versioneer/issues/217). We will go for solution 2. proposed above, which is also proposed here: in this comment.

[BenjaminRodenberg]

I added 44b715d on master to make sure that the hash for v2.3.0.1 will not change anymore:

I did a quick experiment locally with the tar balls of the release:

$ sha256sum postDummy_python-bindings-2.3.0.1.tar.gz 
ed4e48729b662680beaa4ee2a9aff724a79e760534c6c58181be739988da2789  postDummy_python-bindings-2.3.0.1.tar.gz

$ sha256sum preDummy_python-bindings-2.3.0.1.tar.gz 
8438f287f04acc3fbd1c7a0adfb407e3b754d90c9987df75a9c06570634cc25e  preDummy_python-bindings-2.3.0.1.tar.gz

Here, preDummy is the tar ball downloaded before pushing the dummy commit 44b715d and postDummy is the tar ball downloaded after the commit was pushed.

[BenjaminRodenberg]

@ajaust do you think we can close this issue now?

[ajaust]

Yes, we can close it, but we should not forget it. :smile:

[BenjaminRodenberg]

In https://github.com/precice/python-bindings/pull/206 the checksum changed again for unclear reasons.

[BenjaminRodenberg]

Since checksums of the latest release keep changing: We could extend the CI to call ./spack checksum --verify -l py-pyprecice regularly.