feat: add ssh_signing_key input for SSH commit signing

[ashwin-ant]

Summary

Add a new ssh_signing_key input that allows passing an SSH signing key for commit signing, as an alternative to the existing use_commit_signing (which uses GitHub API-based commits).

Why

The existing use_commit_signing option uses the GitHub API to create commits, which means it cannot perform complex git operations like rebasing, cherry-picking, or interactive history manipulation. The new ssh_signing_key option enables signed commits while still using the git CLI.

Behavior Matrix

ssh_signing_key	use_commit_signing	Result
not set	false	Regular git commands, no signing
not set	true	GitHub API (MCP server), verified commits
set	false	Git CLI with SSH signing
set	true	Git CLI with SSH signing (ssh_signing_key takes precedence)

Usage

- uses: anthropics/claude-code-action@main
  with:
    ssh_signing_key: ${{ secrets.SSH_SIGNING_KEY }}
    bot_id: "81847"
    bot_name: "claude"

See updated docs in docs/security.md for full setup instructions.

Changes

• Add ssh_signing_key input to action.yml
• Add setupSshSigning and cleanupSshSigning functions in git-config.ts
• Update tag and agent modes to use SSH signing when provided
• Add cleanup step to remove signing key after action completes
• Add tests for SSH signing functionality
• Update documentation in security.md and usage.md

Testing

Tested in https://github.com/ashwin-ant/install-test with verified commits working correctly.

[claude]

SECURITY: Missing .ssh Directory Permissions

The .ssh directory should be created with 0o700 permissions per SSH best practices.

Fix:

await mkdir(sshDir, { recursive: true, mode: 0o700 });

[claude]

Input Validation Missing

The SSH key should be validated before use to catch misconfigurations early and prevent potential injection issues.

Recommendation:

export async function setupSshSigning(sshSigningKey: string): Promise<void> {
  if (!sshSigningKey.trim()) {
    throw new Error("SSH signing key cannot be empty");
  }
  
  if (!sshSigningKey.includes("BEGIN") || !sshSigningKey.includes("PRIVATE KEY")) {
    throw new Error("Invalid SSH private key format");
  }
  
  // ... rest of function
}

[claude]

Performance: Sequential Git Config Commands

These three independent git config operations can be parallelized to save ~20-60ms per run:

await Promise.all([
  $`git config gpg.format ssh`,
  $`git config user.signingkey ${SSH_SIGNING_KEY_PATH}`,
  $`git config commit.gpgsign true`,
]);

[claude]

Inconsistent Error Handling

Agent mode swallows git configuration errors with a comment "Continue anyway", while tag mode (lines 109-114) properly throws errors. This inconsistency could lead to confusing failures later.

Recommendation: Either make both modes consistent, or document why agent mode should continue on error. Users deserve clear error messages when git setup fails.

[claude]

Code Duplication

This SSH signing detection and git configuration logic (lines 86-118) is duplicated in tag mode (lines 96-128 in src/modes/tag/index.ts). This violates DRY principles and creates maintenance burden - note that error handling has already diverged between the two.

Recommendation: Extract this logic into a shared function like configureGitForMode(context, githubToken, throwOnError) in git-config.ts.

[claude]

Test Coverage Gap: No Integration Testing

This test manually recreates file operations but never actually calls setupSshSigning(). The tests pass but don't validate the actual behavior.

Critical missing scenarios:

1. No integration test of setupSshSigning() function itself
2. Git config commands (git config gpg.format ssh, etc.) are never tested
3. Error handling completely untested (invalid keys, permission failures, git command failures)
4. Mode integration not tested (tag/agent mode SSH signing paths)

Recommendation: Add integration tests that call the actual functions and verify git configuration.

[claude]

Comprehensive Code Review Summary

I've completed a thorough review of PR #784 using specialized review agents for code quality, performance, security, test coverage, and documentation. Here are the key findings:

Critical Issues

🔴 SECURITY: SSH Private Key Exposure Risk
The ssh_signing_key is included in the ALL_INPUTS JSON (action.yml:195) which could expose it in logs. This secret should be excluded from ALL_INPUTS and handled separately.

🔴 SECURITY: Race Condition in File Permissions
The SSH key is written then chmod'd in separate operations (git-config.ts:75-76), creating a brief window with insecure permissions. Use writeFile(path, data, { mode: 0o600 }) instead.

🔴 SECURITY: Missing .ssh Directory Permissions
The .ssh directory should be created with mode: 0o700 (git-config.ts:72).

High Priority Issues

⚠️ Code Duplication
SSH signing setup logic is duplicated between tag and agent modes. This has already caused error handling to diverge between the two. Recommend extracting to a shared configureGitForMode() function.

⚠️ Inconsistent Error Handling
Agent mode swallows git config errors (agent/index.ts:99-104) while tag mode throws. This could lead to confusing failures later.

⚠️ Test Coverage Gaps
Tests simulate file operations but never call the actual setupSshSigning() function. Critical missing scenarios:

• No integration tests of the actual functions
• Git config commands never tested
• Error handling completely untested
• Mode integration not tested

⚠️ Missing Input Validation
SSH key format should be validated before use to catch misconfigurations early and prevent potential issues.

Medium Priority

💡 Performance Optimization
Three independent git config commands (git-config.ts:80-82) can be parallelized with Promise.all() to save ~20-60ms per run.

Positive Aspects

✅ Well-structured code with clean separation of concerns
✅ Proper cleanup with if: always() in action.yml
✅ Correct file permissions (0o600) for SSH keys
✅ Clear precedence logic (SSH signing takes precedence over API signing)
✅ Comprehensive and accurate documentation
✅ Good test coverage for mode detection logic

Documentation

The documentation is accurate and comprehensive. Setup instructions are clear and include all necessary security considerations. No changes required.

Recommendation

Address the three critical security issues before merging. The code duplication and test coverage gaps should also be resolved to ensure maintainability and reliability.