DietPi 2/3/4/Zero 2 archive available on DietPi.com does not match given checksum

[MattChiswell]

Not sure where to bring this up so apologies if it's in the wrong place.

Had the need for a fresh DietPi image for a RaspberryPi 3, went to DietPi.com to download as usual, grabbed both the checksum and signature files to verify as always. Upon checking, the SHA256 checksum is not valid, it has a date from around the time of the previous release, so maybe it wasn't updated? The signature appears to validate correctly and has a much more recent date that lines up with the latest release. Just wanted to bring it up, not sure how many people even check these things but it made me pause and think for a moment!

The downloaded files (with original modification timestamps intact):

-rw-rw-r-- 1 dietpi dietpi 178303328 Oct 21 20:24 DietPi_RPi234-ARMv8-Trixie.img.xz
-rw-rw-r-- 1 dietpi dietpi       833 Oct 21 20:24 DietPi_RPi234-ARMv8-Trixie.img.xz.asc
-rw-rw-r-- 1 dietpi dietpi       100 Sep 22 17:26 DietPi_RPi234-ARMv8-Trixie.img.xz.sha256

Running a comparison shows the sha256 checksums do not match:

shasum -c DietPi_RPi234-ARMv8-Trixie.img.xz.sha256

DietPi_RPi234-ARMv8-Trixie.img.xz: FAILED
shasum: WARNING: 1 computed checksum did NOT match

Manually comparing confirms this:

shasum -a 256 DietPi_RPi234-ARMv8-Trixie.img.xz >> DietPi_RPi234-ARMv8-Trixie.img.xz.sha256
cat DietPi_RPi234-ARMv8-Trixie.img.xz.sha256

14814f261c8c42cb59a96d9933671fe1be2e39cdff086ac8bfd81b2c21faf96b  DietPi_RPi234-ARMv8-Trixie.img.xz
85cf0b586abc3be2cb10277f5c5156ab32f81413c97d8eaec358153237ca1bc3  DietPi_RPi234-ARMv8-Trixie.img.xz

The signature does show file integrity:

gpg --verify DietPi_RPi234-ARMv8-Trixie.img.xz.asc

gpg: assuming signed data in 'DietPi_RPi234-ARMv8-Trixie.img.xz'
gpg: Signature made Tue 21 Oct 20:15:30 2025 BST
gpg:                using RSA key C2C4D1DEF7C96C6EDF3937B2536B2A4A2E72D870
gpg: Good signature from "MichaIng <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9741 05F4 9430 4547 F1A9  E5E0 0442 B9AD E656 43FE
     Subkey fingerprint: C2C4 D1DE F7C9 6C6E DF39  37B2 536B 2A4A 2E72 D870

Again, apologies if this isn't the place for such a report.

[Joulinar]

maybe the Cloudflare cache has not been updated fully. Something @MichaIng can check

[Joulinar]

looking to our download site (https://dietpi.com/downloads/images/), all seems to match

[MichaIng]

85cf0b586abc3be2cb10277f5c5156ab32f81413c97d8eaec358153237ca1bc3 is the correct hash, matching the one on our server. So yeah, seems this one was not purged from the Cloudflare cache. Annoying how unreliable this is. Since we have pro plan, there is a recursive/prefix cache clear function available now. Maybe that one works better.

[MichaIng]

Okay cache cleared. I implemented the prefix method on our server now. For this particular case is doesn't make a difference: We faced this a lot of times, and it always affected only a small share of files on certain Cloudflare edges somehow not being cleared. Rerunning the purge API command always fixed it for all cases. But I hope the prefix method is more reliably applied by the Cloudflare API servers/edges.

Now I remember I even opened a topic about this on their forum: https://community.cloudflare.com/t/739737
With pro plan, I can open a real support ticket 🙂.