Skip to content

The signing key, required hooks and sign-off identity are resolved in Go #931

Description

@tbhb-agent

Problem

packages/agents/source/lib/signing.sh still decides in shell which public key signs an unattended commit, whether the required hooks are present with the configured marker, and what Git state is captured before the commit. dt_signoff_identity in packages/agents/source/lib/lib.sh picks the DCO identity from machine configuration or Git. The landed-commit verification is ported by #764, and internal/signing already has the machine-only signing configuration. This issue ports the rest of the signing and identity logic behind agentrepo, keeping the pre-commit state compatible with what #764 verifies.

Part of #588 and #321. Replaces dt_signing_key, dt_agent_signing, dt_agent_before_commit in packages/agents/source/lib/signing.sh and dt_signoff_identity in packages/agents/source/lib/lib.sh.

Acceptance criteria

  1. AC1: Given gpg.format not ssh, when an unattended commit starts, then it refuses with a diagnostic naming the setting.
  2. AC2: Given user.signingkey as an inline key:: value, a literal public key, or a path with or without the .pub suffix, when the key is resolved, then the key type and body are returned, and given an unreadable path, then it refuses.
  3. AC3: Given a ~/ path in user.signingkey, when the key is resolved, then the home directory is expanded.
  4. AC4: Given each accepted required-hook configuration (hook present, executable and carrying the configured marker), when the commit starts, then it proceeds; and given a required hook that is missing, not executable, or lacking the configured marker, or an unknown hook name, or an empty hook list or marker, then it refuses naming the hook or key.
  5. AC5: Given the branch changed since the review, when the commit starts, then it refuses.
  6. AC6: Given the branch unchanged since the review, when the commit starts, then the pre-commit state records the message text and the reflog size, and the landed-commit verification of refactor(agents): port skill signing verification to Go #764 accepts it and uses it.
  7. AC7: Given signoff_identity in machine configuration, then it is used after the identity check; given none, then the Git name and email are used; given a rejected identity (each rejected form in the existing shell checks) with none configured, then the diagnostic names the machine settings to set.
  8. AC8: Given signoff_identity in the repository configuration, then it never supplies the sign-off identity, whether the configuration reader ignores or rejects it.
  9. AC9: Given a consumer binary that lacks the replacement, when the wrapper runs, then it falls back to the frozen shell behavior and the N-2 compatibility policy holds; and given a present replacement that fails or returns unusable output, then the commit refuses with no fallback to the shell; each of the three cases (absent, failing, unusable output) is observable on its own.
  10. AC10: Given the generated skills, when mise run generate-skills runs, then the output is regenerated, mise run check-generated-skills passes, and the local deployments carry the regenerated wrappers.
  11. AC11: Non-functional: the Go tests pass on Linux, macOS and Windows in CI, with real disposable SSH key fixtures.

Scope and non-goals

Scope: key selection, hook readiness, the pre-commit state and the sign-off identity.

Non-goal: the post-commit verification (#764). Non-goal: changing key handling in internal/signing. Non-goal: removing the shell fallback.

Approach

Meet AC1 to AC11 with failing cases first. The mechanism is the implementer's choice within those outcomes, provided the pre-commit state is accepted by the verifier #764 has already landed. This issue lands after #764, verifier first, so every new signing path is verified from its first commit; no transitional compatibility work exists.

Dependencies

Blocked by: #926 (the generator child that drives the library copies from an explicit list, so that removing a source reference regenerates no protected deletion), #755 (context discovery and path expansion), #764 (landed-commit verification, so AC6 is checked against the real verifier), #753 (golden-file protection for the Go enforcement paths, before enforcement callers switch to Go).

Size

S. One pull request, checked against the landed verifier; redesigning the verifier is out of scope.

Verify plan

  • AC1, AC2, AC3: Go table tests with scratch repositories and disposable SSH keys.
  • AC4: Go tests with hook fixtures covering each accepted configuration and each refusal.
  • AC5: a Go test that moves the branch between review and commit start.
  • AC6: a Go test that takes the pre-commit state and passes it to refactor(agents): port skill signing verification to Go #764's verifier after a real commit in a scratch repository.
  • AC7: Go tests over machine configuration, Git fallback and each rejected identity form.
  • AC8: Go tests with signoff_identity set in repository configuration.
  • AC9: three Bats cases. A binary stub without the subcommand: assert the wrapper falls back to the frozen shell behavior and its result equals the shell's. A present stub replacement that exits non-zero, and a present stub replacement that returns unusable output: assert in each the commit refuses and the shell is not run.
  • AC10: mise run generate-skills leaves no diff, mise run check-generated-skills passes, and a listing of the local deployment shows the regenerated wrappers.
  • AC11: the CI matrix jobs for the Go packages.
  • Definition of done: D1 each AC is verified at the merged head, with the commands and results cited in the pull request's Verification. D2 an independent review approves the exact merged head, and every finding has a recorded disposition. D3 required checks pass with no gate loosened. D4 the leak scans the repository specifies are clean, and every post made for this work passes the per-post leak review before it is posted. D5 every commit is signed. D6 the documentation matches the change or the Verification says why there is no impact. D7 every commit has an Assisted-by trailer and the pull request has the provenance:agent-assisted label. D8 the pull request stays within the size limits. D9 follow-ups are filed as issues and listed under Related. D10 the merge closes the issue through a closing reference, the board shows Done, and the final Status: comment names the merge commit.

Risks

A wrong key or hook rule could let an unsigned commit through the unattended path. Undo: revert the change, which restores the shell functions.

Operator authority

Owner-only GitHub action: the owner's exact-head review. Owner-tier paths named: packages/agents/source/lib/lib.sh, packages/agents/source/lib/signing.sh and their generated scripts/lib.sh and scripts/signing.sh copies are on the golden, owner and constitutional path lists in .agents/agent-skills.conf, so the pull request needs the owner's exact-head review at merge.

Activity

  1. tbhb-agent commented on Oct 27, 2026

    @tbhb-agent
    ContributorAuthor

    Refinement: READY — The signing key, required hooks and sign-off identity are resolved in Go
    Model: gpt-6-astra

    Child 05 The signing key, required hooks and sign-off identity are resolved in Go

    Verdict: READY

    Checked: The new generator prerequisite preserves protected generated copies until their cutovers. Verifier-first ordering, absent-capability fallback, supported-command refusal and machine-only identity remain consistent with packages/agents/source/lib/signing.sh:23, :44, :55 and packages/agents/source/lib/lib.sh:246.

    Gaps: None.

    Split: S remains plausible; no further split established.

    Definition of done

    The definition of done for this issue (Feature). Tick each item and give its evidence.

    • D1 The author verified each AC on the merged head, and the Verification section of the pull request cites each AC ID with its evidence: the command and its result, or a link.
    • D2 An independent reviewer approved the exact merged head, and the author resolved each finding or filed it as a follow-up.
    • D3 The required checks pass on that head, and any loosened gate has the owner's approval of that exact head.
    • D4 The leak scans come back clean: gitleaks, devtools' check-leaks.sh with the repository's private-strings list, and the leak review of each post.
    • D5 The author signed each commit, the squash included.
    • D6 The docs match the change (README, docs/, CHANGELOG or help text), or the Verification section says "No doc impact" and why.
    • D7 The commits and the squash have Assisted-by trailers, and the pull request has the provenance:agent-assisted label.
    • D8 The pull request stays within the size limits, or the owner approved its exact head over the hard limit.
    • D9 The author files follow-ups and deferred findings as issues with at least a Problem and numbered AC and lists them under the Related section of the pull request. Any work left in the code links its issue.
    • D10 The merge closes the issue through a closing reference and the board shows Done. The final Status: comment names the merge commit.
    • devtools-1 mise run check is green, and so are the coverage floors mise run cover-go-check and mise run cover-py-check, which check doesn't run.
    • devtools-2 A change to skill sources under packages/agents/source/ commits what mise run generate-skills, then mise run skill-tokens, then apm install rewrite, in that order, and check-generated-skills (part of lint) passes.
    • devtools-3 A consumer-visible change (the vendored payload, a skill, a reusable workflow, a task or a pin) has its consumer steps in docs/agent-skills-migration.md or the adoption docs, or the PR's Verification says "No consumer impact" and why.

    Round: 3 of 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    refinement:readyPassed the Definition of Ready; may be picked up

    Fields

    Priority

    None yet

    Work type

    None yet

    Projects

    • Status
      Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions