forge-sync: the forge-key recipient cross-check compares key comments, so a template host always fails it #90

New issue

Closed

opened 2026-10-09 21:04:43 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-09 21:04:43 +01:00

forge-sync forge on a hypervisor built from the public template creates both accounts and then refuses to write the dev VM's forge key, on every run.

Evidence, laptop, clean install with every earlier fix pinned through, 2026-10-09:

Error: secrets.nix derives different recipients for secrets/allod-dev-forge-key.age than this run encrypted to; nothing written
Completed before this failure:
-   created human account 'evan'
-   created agent account 'allod-agent'

Cause, read from the scripts: ensure_vm_forge_key builds its recipient list from cat ~/.ssh/host.pub, whose comment is nexus-host (getting-started.sh generates it with ssh-keygen -C "${HYPERVISOR}-host"), and compares it line for line with what secrets.nix derives, where the host key is identity's hostPublicKey, written by the same script with the comment nexus. Same key, different comment, so the sorted lists differ. The other two recipient checks in the command (assert_host_recipient, verify_token_recipients_include) already compare by key material; this one does not. The stub suite's fixture spells the host key identically on both sides, which is why it passed.

Workaround: sed -i 's/ nexus-host$/ nexus/' ~/.ssh/host.pub, then rerun; the comment is not part of the key.

`forge-sync forge` on a hypervisor built from the public template creates both accounts and then refuses to write the dev VM's forge key, on every run. Evidence, laptop, clean install with every earlier fix pinned through, 2026-10-09: Error: secrets.nix derives different recipients for secrets/allod-dev-forge-key.age than this run encrypted to; nothing written Completed before this failure: - created human account 'evan' - created agent account 'allod-agent' Cause, read from the scripts: `ensure_vm_forge_key` builds its recipient list from `cat ~/.ssh/host.pub`, whose comment is `nexus-host` (`getting-started.sh` generates it with `ssh-keygen -C "${HYPERVISOR}-host"`), and compares it line for line with what `secrets.nix` derives, where the host key is identity's `hostPublicKey`, written by the same script with the comment `nexus`. Same key, different comment, so the sorted lists differ. The other two recipient checks in the command (`assert_host_recipient`, `verify_token_recipients_include`) already compare by key material; this one does not. The stub suite's fixture spells the host key identically on both sides, which is why it passed. Workaround: `sed -i 's/ nexus-host$/ nexus/' ~/.ssh/host.pub`, then rerun; the comment is not part of the key.

vnprc referenced this issue from a commit

2026-10-09 21:12:47 +01:00

forge-sync: compare forge-key recipients by key material, not by line

vnprc-agent referenced this issue from allod/strategy

2026-10-09 23:10:21 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

vnprc-agent commented

2026-10-10 13:42:59 +01:00

Author

Landed on allod/nexus master cfc30f6: the forge-key recipient cross-check compares key material, not whole lines; bbcbb2f and 59bf75c beside it print the forge URL and drop the closing block's push lines. Pinned through the deploy template.

Landed on allod/nexus master cfc30f6: the forge-key recipient cross-check compares key material, not whole lines; bbcbb2f and 59bf75c beside it print the forge URL and drop the closing block's push lines. Pinned through the deploy template.

vnprc-agent closed this issue

2026-10-10 13:42:59 +01:00