signing: offer to configure the clone from the user's existing key when the signing check refuses #663

New issue

Open

opened 2026-09-29 17:48:31 +00:00 by hexajon · 0 comments

hexajon commented

2026-09-29 17:48:31 +00:00

Owner

ADR 0013 says that a refusal of the signing check is actionable. madtea offers to configure the clone (gpg.format, user.signingkey, commit.gpgsign) from the user's existing signing key. No code builds this offer. Today each refusal only lists the standard git steps. I dropped this part when #424 closed. I want it back, so this issue tracks the build.

Scope:

Find the user's existing signing key where git already looks for one: the global user.signingkey with its gpg.format, an ssh-agent key, or a gpg secret key.
On each refusal of the signing check, offer to set the clone's gpg.format, user.signingkey, and commit.gpgsign to that key. This covers both refusals: the local check before a push, and the forge check in finish.
Write nothing without the user's yes. madtea never stores or copies key material (ADR 0013).
When no key is found, the refusal lists the standard git steps, as it does today.

Acceptance:

A test against the live forge, with a test repo that requires signed commits: an unsigned commit is refused, and the offer names the key it found. After the user accepts, the clone's config holds the three keys, and the next commit is signed.
madtea writes no key material outside git config, and the secure backend does not change.

Decision record: ADR 0013.

ADR 0013 says that a refusal of the signing check is actionable. madtea offers to configure the clone (`gpg.format`, `user.signingkey`, `commit.gpgsign`) from the user's existing signing key. No code builds this offer. Today each refusal only lists the standard git steps. I dropped this part when #424 closed. I want it back, so this issue tracks the build. Scope: - Find the user's existing signing key where git already looks for one: the global `user.signingkey` with its `gpg.format`, an ssh-agent key, or a gpg secret key. - On each refusal of the signing check, offer to set the clone's `gpg.format`, `user.signingkey`, and `commit.gpgsign` to that key. This covers both refusals: the local check before a push, and the forge check in `finish`. - Write nothing without the user's yes. madtea never stores or copies key material (ADR 0013). - When no key is found, the refusal lists the standard git steps, as it does today. Acceptance: - A test against the live forge, with a test repo that requires signed commits: an unsigned commit is refused, and the offer names the key it found. After the user accepts, the clone's config holds the three keys, and the next commit is signed. - madtea writes no key material outside git config, and the secure backend does not change. Decision record: ADR 0013.

hexajon referenced this issue

2026-09-29 18:52:59 +00:00

docs(adr): consolidate the decision records into their end-state form #667

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#663

No description provided.

Rows
Columns