fix: re-sign the unsigned commits on main and configure commit signing

hexajon commented

2026-08-17 15:51:05 +00:00

Owner

Problem

Six commits landed with NO GPG signature (sig=N), while all prior history is signed with key 6E62A0A72715C1F6 (hexajon). Author and committer are correctly hexajon <jon@sixfold.space> on all of them. Only the signature is missing.

Unsigned commits:

On main: 2568aa79, d5032b34, 1de91fc5, dad0a1a1, fedf9040
On branch docs/prelaunch-marker-tracking: 1d90b2fd

Root cause

They were committed from a clone whose git config had no signing set: commit.gpgsign, user.signingkey, and gpg.format were all empty. madt_commit set author and committer to hexajon, but nothing signed the commits.

Fix

Configure signing in the working checkout: user.signingkey=6E62A0A72715C1F6, commit.gpgsign=true, and tag.gpgsign to match. This needs the hexajon secret key present in that environment.
Re-sign the commits. Author and committer are already correct, so only the signature is added: git rebase 49cad064 --exec 'git commit --amend --no-edit -S' over the branch covers the main range plus 1d90b2fd, or amend per commit.
Re-signing rewrites the commit hashes, so the re-signed main needs a force-push to main. I run that step by hand, because rewriting merged history on main is not something to automate.

Constraints

The signing key is a credential. Never commit it or expose it, and do not import it into a throwaway clone. If signing fails, the key is simply not present in that environment, so do the work where the key already lives.
The force-push and the history rewrite are manual steps.
Fix the config gap too, so future commits from any clone sign by default.

## Problem Six commits landed with NO GPG signature (`sig=N`), while all prior history is signed with key `6E62A0A72715C1F6` (hexajon). Author and committer are correctly `hexajon <jon@sixfold.space>` on all of them. Only the signature is missing. Unsigned commits: - On `main`: `2568aa79`, `d5032b34`, `1de91fc5`, `dad0a1a1`, `fedf9040` - On branch `docs/prelaunch-marker-tracking`: `1d90b2fd` ## Root cause They were committed from a clone whose git config had no signing set: `commit.gpgsign`, `user.signingkey`, and `gpg.format` were all empty. `madt_commit` set author and committer to hexajon, but nothing signed the commits. ## Fix 1. Configure signing in the working checkout: `user.signingkey=6E62A0A72715C1F6`, `commit.gpgsign=true`, and `tag.gpgsign` to match. This needs the hexajon secret key present in that environment. 2. Re-sign the commits. Author and committer are already correct, so only the signature is added: `git rebase 49cad064 --exec 'git commit --amend --no-edit -S'` over the branch covers the main range plus `1d90b2fd`, or amend per commit. 3. Re-signing rewrites the commit hashes, so the re-signed `main` needs a **force-push to `main`**. I run that step by hand, because rewriting merged history on `main` is not something to automate. ## Constraints - The signing key is a credential. Never commit it or expose it, and do not import it into a throwaway clone. If signing fails, the key is simply not present in that environment, so do the work where the key already lives. - The force-push and the history rewrite are manual steps. - Fix the config gap too, so future commits from any clone sign by default.

hexajon added the

bug

severity/high

status/needs-decision

labels

2026-08-17 15:51:05 +00:00

hexajon commented

2026-08-17 15:51:09 +00:00

Author

Owner

This has to be done from the checkout that holds the signing key, and by hand. From that checkout: configure signing, run git rebase 49cad064 --exec 'git commit --amend --no-edit -S' over the range, then force-push main. Closing the config gap (commit.gpgsign / user.signingkey / gpg.format unset in a fresh clone) only helps in an environment where the key is already present, which is the underlying weakness.

#424 tracks making signing travel with the forge credential, so this stops recurring.

This has to be done from the checkout that holds the signing key, and by hand. From that checkout: configure signing, run `git rebase 49cad064 --exec 'git commit --amend --no-edit -S'` over the range, then force-push `main`. Closing the config gap (`commit.gpgsign` / `user.signingkey` / `gpg.format` unset in a fresh clone) only helps in an environment where the key is already present, which is the underlying weakness. #424 tracks making signing travel with the forge credential, so this stops recurring.

hexajon referenced this issue

2026-08-17 15:57:38 +00:00

fix: commit author/committer come from the global git identity, not the target repo; verify identity + signing before push #425

hexajon referenced this issue

2026-08-17 15:58:38 +00:00

feat: adopt madtea.lol vanity import path and route distribution through the GitHub edge #420

hexajon self-assigned this

2026-08-17 17:45:48 +00:00

hexajon referenced this issue

2026-08-17 18:54:19 +00:00

fix(repos): madt_repos edit lacks fast-forward-only + rebase-explicit merge flags and mislabels allow_rebase_update #432

hexajon referenced this issue

2026-08-17 21:15:01 +00:00

fix: 45 server-side merge commits on main carry the forge noreply identity, not jon@sixfold.space #436

hexajon commented

2026-09-08 19:09:28 +00:00

Author

Owner

Decided: re-sign the six unsigned commits via a history rewrite, as a manual by-hand step.

#436 chose to accept the 45 noreply commits, so this rewrite stays shallow: only the six correctly-authored-but-unsigned commits get amended and re-signed.

Recipe, run by hand from the checkout holding signing key 6E62A0A72715C1F6:

git rebase 49cad064 --exec 'git commit --amend --no-edit -S'
then force-push main by hand.

This rewrites the six commit hashes and every downstream + mirror hash, so it is a deliberate by-hand operation, not a madtea flow, and not something an agent runs (force-push is guarded). Recurrence is already prevented by the #424 config fix. Clearing needs-decision: the decision is made; the force-push remains a manual step.

Decided: re-sign the six unsigned commits via a history rewrite, as a manual by-hand step. #436 chose to accept the 45 noreply commits, so this rewrite stays shallow: only the six correctly-authored-but-unsigned commits get amended and re-signed. Recipe, run by hand from the checkout holding signing key 6E62A0A72715C1F6: - `git rebase 49cad064 --exec 'git commit --amend --no-edit -S'` - then force-push `main` by hand. This rewrites the six commit hashes and every downstream + mirror hash, so it is a deliberate by-hand operation, not a madtea flow, and not something an agent runs (force-push is guarded). Recurrence is already prevented by the #424 config fix. Clearing needs-decision: the decision is made; the force-push remains a manual step.

hexajon removed the

status/needs-decision

label

2026-09-08 19:09:30 +00:00

hexajon referenced this issue

2026-09-08 19:09:32 +00:00

fix: 45 server-side merge commits on main carry the forge noreply identity, not jon@sixfold.space #436

hexajon commented

2026-09-14 18:41:35 +00:00

Author

Owner

Resolved. main carries a signed copy of each unsigned commit, so no rewrite is left to do.

Evidence (checked 2026-09-14, main at bba01b38):

The five unsigned commits were the pre-rewrite copies from PR #382. main has a signed replacement for each one, with the same tree and the same patch-id:
- 2568aa79 -> 7b1f4a1b
- d5032b34 -> 7b32350c
- 1de91fc5 -> b95d4347
- dad0a1a1 -> 4b410d08
- fedf9040 -> ef0e6887
7b1f4a1b sits directly on 49cad064. All five replacements are signed with key 6E62A0A72715C1F6.
The forge verification API reports 43 of the 44 commits in 49cad064..main as verified=true, signed by 6E62A0A72715C1F6. The one exception is a72431b7. It is a server-side merge commit with the noreply identity, which is the #436 case.
Since signing started on 2026-07-13, main has 0 unsigned non-merge commits. All 39 unsigned commits in that range are server-side merge commits with a noreply identity (#436).
1d90b2fd is no longer in any branch.
I deleted the stale branch feat/madtea-lol-vanity-path. It held only the five unsigned originals. PR #382 was already merged, and no open PR used the branch.

To stop this from happening again: the pre-push signature guard (9bce364d) and #424 cover it.

Resolved. `main` carries a signed copy of each unsigned commit, so no rewrite is left to do. Evidence (checked 2026-09-14, `main` at `bba01b38`): - The five unsigned commits were the pre-rewrite copies from PR #382. `main` has a signed replacement for each one, with the same tree and the same patch-id: - `2568aa79` -> `7b1f4a1b` - `d5032b34` -> `7b32350c` - `1de91fc5` -> `b95d4347` - `dad0a1a1` -> `4b410d08` - `fedf9040` -> `ef0e6887` - `7b1f4a1b` sits directly on `49cad064`. All five replacements are signed with key `6E62A0A72715C1F6`. - The forge verification API reports 43 of the 44 commits in `49cad064..main` as `verified=true`, signed by `6E62A0A72715C1F6`. The one exception is `a72431b7`. It is a server-side merge commit with the noreply identity, which is the #436 case. - Since signing started on 2026-07-13, `main` has 0 unsigned non-merge commits. All 39 unsigned commits in that range are server-side merge commits with a noreply identity (#436). - `1d90b2fd` is no longer in any branch. - I deleted the stale branch `feat/madtea-lol-vanity-path`. It held only the five unsigned originals. PR #382 was already merged, and no open PR used the branch. To stop this from happening again: the pre-push signature guard (`9bce364d`) and #424 cover it.

hexajon closed this issue

2026-09-14 18:41:35 +00:00

Rows
Columns

fix: re-sign the unsigned commits on main and configure commit signing #422

Problem

Root cause

Fix

Constraints