tauri-plugin-updater with a minisign keypair (public key in tauri.conf.json, private key in Gitea secrets), a latest.json manifest written by the release workflow and served from the same host as the dnf repo, and a capability entry for the updater with a reason. The RPM path opts out (dnf owns updates); AppImage, NSIS and dmg opt in. The UI shows an update as an offer, never applies it silently.
Acceptance
Run version N of the AppImage, publish N+1, see the offer, accept, and be on N+1. A manifest signed with the wrong key is refused.
Depends on
The release workflow; the Windows/macOS builders for those targets.
Parent: #5
## Scope
`tauri-plugin-updater` with a minisign keypair (public key in `tauri.conf.json`, private key in Gitea secrets), a `latest.json` manifest written by the release workflow and served from the same host as the dnf repo, and a capability entry for the updater with a reason. The RPM path opts out (dnf owns updates); AppImage, NSIS and dmg opt in. The UI shows an update as an offer, never applies it silently.
## Acceptance
Run version N of the AppImage, publish N+1, see the offer, accept, and be on N+1. A manifest signed with the wrong key is refused.
## Depends on
The release workflow; the Windows/macOS builders for those targets.
grenade
added the child label 2026-09-15 12:41:45 +00:00
The first manifest is live at https://rpm.lair.cafe/blackbeard-wallet/latest.json: version 0.1.0, linux-x86_64 pointing at the release's AppImage. Its signature verifies against the public key in tauri.conf.json (key id 442BF0EADEA536C9, Ed25519 over the BLAKE2b prehash), checked independently of the plugin. The acceptance needs two releases: run the 0.1.0 AppImage, publish 0.1.1, accept the offer, land on 0.1.1. That waits on the next tag. Windows and macOS entries arrive with #34.
The first manifest is live at `https://rpm.lair.cafe/blackbeard-wallet/latest.json`: version 0.1.0, `linux-x86_64` pointing at the release's AppImage. Its signature verifies against the public key in `tauri.conf.json` (key id `442BF0EADEA536C9`, Ed25519 over the BLAKE2b prehash), checked independently of the plugin. The acceptance needs two releases: run the 0.1.0 AppImage, publish 0.1.1, accept the offer, land on 0.1.1. That waits on the next tag. Windows and macOS entries arrive with #34.
The update path works end to end with 0.1.0 → 0.2.0 (release run 7876):
Ran the published blackbeard-wallet_0.1.0_amd64.AppImage (it reports install appimage, updater on) and unlocked a wallet.
Three seconds later the shell showed "blackbeard wallet 0.2.0 is available (you have 0.1.0)" with "Update and restart" and "Not now"; nothing was applied until the button was pressed.
Accepted: the AppImage file on disk was replaced (--version now prints blackbeard-wallet 0.2.0), the app relaunched to the lock screen, and app_info in the relaunched process reports 0.2.0.
The manifest's AppImage signature was also verified independently against the public key in tauri.conf.json for 0.1.0. Still owed for the acceptance: the negative case, a manifest signed with a different key refused. That needs a manifest served at the configured endpoint with a wrong signature, which I have not staged against the live rpm.lair.cafe path. Windows and macOS entries come with #34.
The update path works end to end with 0.1.0 → 0.2.0 (release run 7876):
1. Ran the published `blackbeard-wallet_0.1.0_amd64.AppImage` (it reports install `appimage`, updater on) and unlocked a wallet.
2. Three seconds later the shell showed "blackbeard wallet 0.2.0 is available (you have 0.1.0)" with "Update and restart" and "Not now"; nothing was applied until the button was pressed.
3. Accepted: the AppImage file on disk was replaced (`--version` now prints `blackbeard-wallet 0.2.0`), the app relaunched to the lock screen, and `app_info` in the relaunched process reports `0.2.0`.
The manifest's AppImage signature was also verified independently against the public key in `tauri.conf.json` for 0.1.0. Still owed for the acceptance: the negative case, a manifest signed with a different key refused. That needs a manifest served at the configured endpoint with a wrong signature, which I have not staged against the live `rpm.lair.cafe` path. Windows and macOS entries come with #34.
Operator decision, 2026-09-16: the wrong-key case is not worth staging. Refusing a manifest whose signature does not match the configured public key is tauri-plugin-updater's own verification (minisign-verify), not code in this repository; a bug there belongs to the plugin. What this repository owns is the key in tauri.conf.json, the signing in the release workflow and the manifest it publishes, and those are proven by the 0.1.0 → 0.2.0 update above. Closing. Windows and macOS manifest entries arrive with their builders in #34.
Operator decision, 2026-09-16: the wrong-key case is not worth staging. Refusing a manifest whose signature does not match the configured public key is `tauri-plugin-updater`'s own verification (minisign-verify), not code in this repository; a bug there belongs to the plugin. What this repository owns is the key in `tauri.conf.json`, the signing in the release workflow and the manifest it publishes, and those are proven by the 0.1.0 → 0.2.0 update above. Closing. Windows and macOS manifest entries arrive with their builders in #34.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Parent: #5
Scope
tauri-plugin-updaterwith a minisign keypair (public key intauri.conf.json, private key in Gitea secrets), alatest.jsonmanifest written by the release workflow and served from the same host as the dnf repo, and a capability entry for the updater with a reason. The RPM path opts out (dnf owns updates); AppImage, NSIS and dmg opt in. The UI shows an update as an offer, never applies it silently.Acceptance
Run version N of the AppImage, publish N+1, see the offer, accept, and be on N+1. A manifest signed with the wrong key is refused.
Depends on
The release workflow; the Windows/macOS builders for those targets.
The first manifest is live at
https://rpm.lair.cafe/blackbeard-wallet/latest.json: version 0.1.0,linux-x86_64pointing at the release's AppImage. Its signature verifies against the public key intauri.conf.json(key id442BF0EADEA536C9, Ed25519 over the BLAKE2b prehash), checked independently of the plugin. The acceptance needs two releases: run the 0.1.0 AppImage, publish 0.1.1, accept the offer, land on 0.1.1. That waits on the next tag. Windows and macOS entries arrive with #34.The update path works end to end with 0.1.0 → 0.2.0 (release run 7876):
blackbeard-wallet_0.1.0_amd64.AppImage(it reports installappimage, updater on) and unlocked a wallet.--versionnow printsblackbeard-wallet 0.2.0), the app relaunched to the lock screen, andapp_infoin the relaunched process reports0.2.0.The manifest's AppImage signature was also verified independently against the public key in
tauri.conf.jsonfor 0.1.0. Still owed for the acceptance: the negative case, a manifest signed with a different key refused. That needs a manifest served at the configured endpoint with a wrong signature, which I have not staged against the liverpm.lair.cafepath. Windows and macOS entries come with #34.Operator decision, 2026-09-16: the wrong-key case is not worth staging. Refusing a manifest whose signature does not match the configured public key is
tauri-plugin-updater's own verification (minisign-verify), not code in this repository; a bug there belongs to the plugin. What this repository owns is the key intauri.conf.json, the signing in the release workflow and the manifest it publishes, and those are proven by the 0.1.0 → 0.2.0 update above. Closing. Windows and macOS manifest entries arrive with their builders in #34.