SHA-256 sum of json-3.10.5.tar.xz changes over time (but not the content itself)

[5balls]

I noticed when running my build toolchain, that the md5sums of this file changed. I could extract an old file from a docker image and confirm this with a recently downloaded version of the file also with SHA-256. The archive contents itself are identical.

What is the issue you have?

I don't necessarily consider it a bug, because the expected behaviour (md5sums or SHA-256 sums of archive remaining constant) is not promised anywhere but maybe this is an artifact of the build process, which can be fixed.

The equivalent zip file does seem to keep the SHA-256 sum I guess - because it is in the description of the release and did not change since the release I think. So maybe something is different about the creation of this zip file (maybe rerun of some github action in case of .tar.xz file involved).

Please describe the steps to reproduce the issue.

1. wget https://github.com/nlohmann/json/releases/download/v3.10.5/json-3.10.5.tar.xz
2. sha256sum json-3.10.5.tar.xz > sha256sum1.txt
3. wait some time (unknown amount. maybe a week)
4. wget https://github.com/nlohmann/json/releases/download/v3.10.5/json-3.10.5.tar.xz
5. sha256sum json-3.10.5.tar.xz > sha256sum2.txt
6. diff sha256sum1.txt sha256sum2.txt

Can you provide a small but working code example?

What is the expected behavior?

SHA-256 sum of release file json-3.10.5.tar.xz does not change.

And what is the actual behavior instead?

SHA-256 sum of release file json-3.10.5.tar.xz does change over time.

Which compiler and operating system are you using?

• Compiler: clang
• Operating system: Debian 11 (stable) & Debian 11 (stable) in docker container

Which version of the library did you use?

• latest release version 3.10.5
• other release - please state the version: ___
• the develop branch

If you experience a compilation error: can you compile and run the unit tests?

• yes
• no - please copy/paste the error message below

[nlohmann]

Thanks for reporting. The feature of having the xz files is experimental still (see discussion #3255). I am still struggling to make the tar.xz creation reproducible. The content already is, but it seems that the tar hash changes every time I re-create the archive.

Any idea how to fix this?

Once I know how to make the archive creation reproducible, I will officially announce the feature and will also list the expected hash in the release notes.

[5balls]

Currently at work - I can have a closer look at it this evening concerning the differences between the different files on a tar level. Maybe this stackoverflow answer points in the right direction:

https://stackoverflow.com/a/54908072

[gregmarr]

Yes, it is most likely the timestamps. Why do you need to recreate and republish the archive?

[5balls]

I don't need to or want to recreate or republish the archive myself. I just pull the file from github in a build script for my own software and the checksum changes when I do this at different times.

In the interest of reproducible builds on my own part I'd like to get a bit identical tar.xz file.

I was suggesting to fix the workflow/action here at github, which creates this file, so that the downloaded file will always be identical. This might be fixed with giving some options to the tar command, but I'm not sure how this file is created here.

[nlohmann]

Why do you need to recreate and republish the archive?

I had to republish the archive because I forgot a file needed by MSVC.

Of course, this changes the hash etc., but in the end, I want to add a Makefile target to create the file and make it possible for anyone to reproduce this step.

[gregmarr]

@5balls

I don't need to or want to recreate or republish the archive myself.

I know, I was asking @nlohmann. Sorry that wasn't obvious.

I had to republish the archive because I forgot a file needed by MSVC.

That makes sense.

@5balls it sounds like this bit may not be accurate:

The archive contents itself are identical.

Did you only compare file contents, or did you check for new files in the new archive?

If this only changed because a republish because of a broken zip file, and we don't expect this to be a regular thing, then it may not make sense to try to make it so that the archive creation is bitwise reproducible, as long as the contents can be verified.

Once I know how to make the archive creation reproducible, I will officially announce the feature and will also list the expected hash in the release notes.

As long as the release notes aren't part of the archive itself, then you can do that if you publish the archive before the release notes. Otherwise, that's not possible.

If you do list it in the release notes, and you have to publish a new version of the archive because of a missing file, you can always change the archive name from json-3.10.5.tar.xz to json-3.10.5.1.tar.xz and add the new MD5 to the release notes with a note of the differences between the archives.

[5balls]

Did you only compare file contents, or did you check for new files in the new archive?

@gregmarr I think I did a diff on the directories and compared the individual md5sums of the files but I may have overlooked a file (although that should have been caught by the diff). I remember being surprised that the contents were the same. I also downloaded the .zip file and calculated the sha256sum afterwards, and this was matching the one in the release notes. Unfortunately yesterday the power supply of the machine I have the files on seems to have failed, so I will only be able to check this when I have replaced the faulty power supply.

[5balls]

If this only changed because a republish because of a broken zip file, and we don't expect this to be a regular thing, then it may not make sense to try to make it so that the archive creation is bitwise reproducible, as long as the contents can be verified.

@gregmarr Ah, yes, if the archive was just recreated due to manual intervention of @nlohmann in this case and it is a rare occurence I'm fine with that. I thought it could have been an - on the fly running github action - like encoding the archive at the time when downloading or something like that. I only thought that, because it was already released with a version tag and I thought it would be "frozen". Of course it would be a nice thing, if anyone could reproduce the archive with the identical hash at any time.

[theShmoo]

Maybe it would be good practice to create a new version if something changes?

[nlohmann]

This feature is still experimental. I added the xz files to the releases to test whether everything works as expected with FetchContent. Once this all is stable, there will be a single xz archive per release with a single (and hopefully reproducible) hash. Until then, don't make any assumption on these files - not even about their presence ;)

[nlohmann]

The feature is now documented: c11f982

Please let me know what you think!