---
title: "Discussion on \"An Auto-Updater That Doesn't Trust Its Download Server: minisign, Verify-Before-Parse and Rollback Protection\" | Hashnode"
description: "Discussion on \"An Auto-Updater That Doesn't Trust Its Download Server: minisign, Verify-Before-Parse and Rollback Protection\". Secure auto-update design: minisign Ed25519 signatures and trusted comments, verify before parsing, rollback protection, safe extraction and per-platform install with rollback."
url: "https://hashnode.com/posts/an-auto-updater-that-doesn-t-trust-its-download-server-minisign-verify-before-parse-and-rollback-protection/6af273d3d52a483b3ddd7416"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [An Auto-Updater That Doesn't Trust Its Download Server: minisign, Verify-Before-Parse and Rollback Protection](https://mistlab.hashnode.dev/an-auto-updater-that-doesn-t-trust-its-download-server-minisign-verify-before-parse-and-rollback-protection?utm_source=hashnode&utm_medium=feed)

Secure auto-update design: minisign Ed25519 signatures and trusted comments, verify before parsing, rollback protection, safe extraction and per-platform install with rollback.

1d ago · 10 min read · mistlab.hashnode.dev  
Read the article

-   [#rust](https://hashnode.com/tag/rust)
-   [#ssh](https://hashnode.com/tag/ssh)
-   [#linux](https://hashnode.com/tag/linux)
-   [#security](https://hashnode.com/tag/security)

## Written by

[c-wind](https://hashnode.com/@c-wind)

@c-wind

  
[View profile](https://hashnode.com/@c-wind)

Building developer tools around SSH and terminals. Rust, Linux, ops.

Building developer tools around SSH and terminals. Rust, Linux, ops.

## Responses 2

Markdown supported · ⌘↵ to post

[Mike Dabydeen](https://hashnode.com/@firelinks)

[1h ago](https://hashnode.com/posts/an-auto-updater-that-doesn-t-trust-its-download-server-minisign-verify-before-parse-and-rollback-protection/6af273d3d52a483b3ddd7416/comment/6af45dc3a4dc7924bbc6e276)

Remembering the highest verified version has a recovery problem when the thing that leaked is a signing key. Someone holding the primary key can sign a manifest for 99.0.0, and every client that checks during that window records it as highest seen, whether or not the user installs it. After that, the real fix, say 1.2.27 signed with the backup key, comes back as StaleManifest, so the release meant to retire the bad key can't reach the clients that saw the attack.

TUF calls this a fast-forward attack, and its client workflow deletes the stored timestamp and snapshot metadata when those keys are rotated. The small equivalent here would be to store the minisign key ID with highest\_seen\_version and keep one ratchet per key. A backup-signed release is then compared only with what the backup key has signed before, and the strictly-greater check against the running version still blocks a downgrade.

[AI Developer](https://hashnode.com/@lycore)

[1d ago](https://hashnode.com/posts/an-auto-updater-that-doesn-t-trust-its-download-server-minisign-verify-before-parse-and-rollback-protection/6af273d3d52a483b3ddd7416/comment/6af2ec913e19241a9e34a7d3)

Remembering the highest verified version blocks rollback to an older manifest, but it cannot detect a mirror indefinitely replaying the newest manifest the client has already seen. A signed expiry or timestamp role plus a reliable clock could bound that freeze window; it is worth making the clock and offline-update trade-off explicit. How is the highest-seen state protected against deletion or corruption?