Catalog checksum mismatch for riddle 0.3.0 and chromium 0.5.0 (assets re-uploaded 12 Jul, pins not refreshed)

[flaviuc]

remagic install riddle fails with:

remagic: riddle: checksum mismatch (corrupted download or tampered catalog)

It is not a corrupt download — the pinned hashes are stale. Same for chromium.

What verifies and what does not

App	Version	Catalog pin	Served asset	Result
riddle	0.3.0	772f45ed…	1f37eac5…	MISMATCH
chromium	0.5.0	e303107c…	5e580163…	MISMATCH
paperterm	0.1.0	d491b7bc…	d491b7bc…	ok
store	0.1.1	0e0761da…	0e0761da…	ok
badapple	0.1.0	7706b6d8…	7706b6d8…	ok

Cause

The release assets for riddle and chromium were re-uploaded after catalog.json pinned them:

	catalog.json commit	asset created_at
riddle 0.3.0	2026-07-07 17:43 (3d2e0be)	2026-07-12 23:30
chromium 0.5.0	2026-07-10 14:14 (fc0618e)	2026-07-12 23:59
paperterm 0.1.0	2026-07-10 14:05 (af4c333)	2026-07-10 14:05

Only the two apps whose assets were re-uploaded on 12 July mismatch. paperterm, store and badapple were untouched and verify fine.

Older versions do not help — every riddle asset (0.1.0, 0.2.0, 0.3.0) was re-uploaded in the same batch, so no currently published asset matches any hash catalog.json has ever contained, including the historical riddle 0.2.0 pin 492e30e0….

Suggested fix

Refresh the sha256 values in catalog.json for riddle 0.3.0 and chromium 0.5.0 to match the assets currently served.

It would also help to confirm publicly that the 12 July re-upload was your own rebuild — from the outside, "release asset silently replaced after publication" is indistinguishable from a supply-chain compromise, and the checksum failure is the only signal users get.

Longer term, publishing a SHA256SUMS per app release (as the remagic CLI release itself does) would let users verify against the upstream project rather than only against the catalog.

Environment

• reMarkable Paper Pro (ferrari), OS 3.27.3.0
• remagic CLI v0.2.0 on Windows (binary verified against its own published SHA256SUMS)