sixfold-space/madtea

SHA256

Fork 0

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

New issue

Open

opened 2026-08-17 15:51:05 +00:00 by hexajon · 2 comments

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

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#422

No description provided.

Rows
Columns