Checksum changed

Using FoundationDB
1

The checksum at https://www.foundationdb.org/downloads/6.1.8/linux/fdb_6.1.8.tar.gz.sha256 changed between 19 and 7 days ago. Is this expected?

 fdb_checksums:
   # https://www.foundationdb.org/downloads/6.1.8/linux/fdb_6.1.8.tar.gz.sha256
-  '6.1.8': sha256:869c8051773591dd953fa2d106d4daeee9b865fe3e2df14b763e980692e80365
+  '6.1.8': sha256:6f0c8d5645f4c1f2dd9714ecce84c3fd0f7b59d3dea13e7ea69d78fe7b561137
2

This is not expected, and thank you for bringing this to our attention.

Digging through things, it appears that this tarball in particular is not a part of our builder’s published artifacts, but is instead dynamically generated as part of deploying the website.

According to the internal repository of artifacts for 6.1.8, the md5 hashes of the individual files in the tarball should be

943a23351d211b9491f59443261fc095  ./files/linux/bin/fdbrestore
e7ec498cd1c3963afff3572fd699b9a3  ./files/linux/bin/fdbcli
943a23351d211b9491f59443261fc095  ./files/linux/bin/dr_agent
943a23351d211b9491f59443261fc095  ./files/linux/bin/backup_agent
68b31c34168578f979958cce4f4b6c2d  ./files/linux/bin/fdbserver
5b3c3772ca107b91a91125844374f0d2  ./files/linux/bin/fdbmonitor
943a23351d211b9491f59443261fc095  ./files/linux/bin/fdbbackup
943a23351d211b9491f59443261fc095  ./files/linux/bin/fdbdr

And I have verified that these hashes are still the same in the public tarball:

$ curl -O https://www.foundationdb.org/downloads/6.1.8/linux/fdb_6.1.8.tar.gz && tar -xzf fdb_6.1.8.tar.gz && cd fdb_binaries
$ md5 *
MD5 (backup_agent) = 943a23351d211b9491f59443261fc095
MD5 (dr_agent) = 943a23351d211b9491f59443261fc095
MD5 (fdbbackup) = 943a23351d211b9491f59443261fc095
MD5 (fdbcli) = e7ec498cd1c3963afff3572fd699b9a3
MD5 (fdbdr) = 943a23351d211b9491f59443261fc095
MD5 (fdbmonitor) = 5b3c3772ca107b91a91125844374f0d2
MD5 (fdbrestore) = 943a23351d211b9491f59443261fc095
MD5 (fdbserver) = 68b31c34168578f979958cce4f4b6c2d

So it appears that we have mistakenly regenerated the tarball, and the hash of it has changed due to the embedded metadata being different. I’ve filed #1970 to track addressing this, as users of this file should always copy the hash rather than download it to guard against malicious replacement, and anything incentivizing doing the opposite is bad.