Experimental Physics and
Industrial Control System

Of course I never download the tarball from git, so I did not notice.

The content of the .VERSION file is generated on the git server at each download (by .gitattributes).

I can imagine it changes when 2.8.22 is no longer the current master HEAD when I uploaded a newer version. It contains

The %D is replaced by the git server.

Hello, all!

I was testing a build of an IOC including StreamDevice with our Nix
build system, and that build system reported that the StreamDevice-
2.8.22.zip archive had a hash mismatch, i.e. the content changed
between when I first packaged it, and when I downloaded it recently.

I compared a previous version and a recent version, and I found that
the `.VERSION` file had a small change:

@@ -1,3 +1,3 @@
COMMIT: 94721c2b0e2ae118778d5783bd35cc642f573f60
-REFS:   HEAD -> master, tag: 2.8.22
+REFS:   tag: 2.8.22
DATE:   2021-11-11 11:49:32 +0100

Obviously, I think there's no functional change between the two, and it
seems the issue arose from the fact that the 2.8.22 tag was also the
master branch before.

But it seems weird to me that GitHub "reuploaded" the tarball, despite
GitHub saying the release was made in 2021-11-11.

It also feels weird that a source tarball of a fixed tagged version is
not itself "fixed". This, to me, feels like a security issue.

Any insights on this? Did anyone encounter this?

Thanks, and have a great day!
--
Rémi NICOLE <remi.nicole at cea.fr>
CEA/DRF/IRFU/DIS/LDISC