Skip to content

Cross-platform robustness and edge cases #5

@bordumb

Description

@bordumb

Epic 7: CLI — Cross-platform robustness and edge cases

Feedback from PR reviewers on the Axios PR (axios/axios#10646) and
from auditing the CLI internals exposed several issues that affect
real-world adoption.

Task 7.1: auths verify — handle shallow repos and short commit histories gracefully

What: auths verify HEAD~2..HEAD~1 fails in a 2-commit repo because
HEAD~2 doesn't exist. The CLI calls git rev-list which emits
fatal: bad revision 'HEAD~2'. While the error is caught, the message
is cryptic and doesn't guide the user to a fix.

Why: The GitHub Action auto-detects commit ranges from PR context
(pr.base.sha..pr.head.sha) so this doesn't hit in CI. But example
scripts and manual CLI usage hit this constantly — especially in demo
repos or new projects with few commits.

File to modify:
/Users/bordumb/workspace/repositories/auths-base/auths/crates/auths-cli/src/commands/verify_commit.rs

Current behavior (lines 198-226):

fn resolve_commits(commit_spec: &str) -> Result<Vec<String>> {
    if commit_spec.contains("..") {
        let output = Command::new("git")
            .args(["rev-list", commit_spec])
            .output()?;
        // On error: "Invalid commit range: {stderr}"
    }
}

Improve: Detect the "bad revision" error pattern and emit a
helpful message:

if stderr.contains("bad revision") || stderr.contains("unknown revision") {
    return Err(anyhow!(
        "Commit range '{}' references commits that don't exist. \
         In a repo with N commits, HEAD~N is invalid. \
         Try 'auths verify HEAD' for the latest commit, \
         or use explicit SHAs.",
        commit_spec
    ));
}

Task 7.2: CLI — cross-platform ssh-keygen availability check

What: The CLI depends on ssh-keygen for commit signature verification
(ssh-keygen -Y find-principals and ssh-keygen -Y verify). On Windows
without OpenSSH installed, auths verify fails with a confusing error.

Why: The CLI already has a check_ssh_keygen() function (line 143 in
verify_commit.rs) that runs ssh-keygen -? as early validation. But the
error message could be more helpful with platform-specific install guidance.

File to modify:
/Users/bordumb/workspace/repositories/auths-base/auths/crates/auths-cli/src/commands/verify_commit.rs

Current check (line 143):

fn check_ssh_keygen() -> Result<()> {
    Command::new("ssh-keygen").arg("-?").output()
        .map_err(|_| anyhow!("ssh-keygen not found"))?;
    Ok(())
}

Improve: Add platform-specific guidance and minimum version check
(SSH signing requires OpenSSH 8.0+):

fn check_ssh_keygen() -> Result<()> {
    let output = Command::new("ssh-keygen").arg("-V").output()
        .map_err(|_| {
            let install_hint = if cfg!(target_os = "macos") {
                "ssh-keygen should be pre-installed on macOS."
            } else if cfg!(target_os = "windows") {
                "Install OpenSSH via Settings > Apps > Optional features, \
                 or install Git for Windows which bundles it."
            } else {
                "Install openssh-client: apt install openssh-client"
            };
            anyhow!("ssh-keygen not found on PATH.\n  {}", install_hint)
        })?;
    // Check version >= 8.0 (required for -Y sign/verify)
    // ...
    Ok(())
}

File reference (existing Windows hint):
/Users/bordumb/workspace/repositories/auths-base/auths/crates/auths-cli/src/errors/renderer.rs
already has a Windows install hint — consolidate with the check function.

Task 7.3: CLI — add auths doctor check for ssh-keygen version

What: The auths doctor command should verify that ssh-keygen is
available AND that it supports the -Y flag (SSH signing, added in
OpenSSH 8.0). Currently system_diagnostic.rs checks availability but
not version.

File to modify:
/Users/bordumb/workspace/repositories/auths-base/auths/crates/auths-cli/src/adapters/system_diagnostic.rs

Add a version-awareness check that parses ssh-keygen -V output
and warns if the version is < 8.0.


Epic 8: GitHub Action — Least-privilege permissions

PR review feedback (axios/axios#10646) flagged that the GitHub Action
workflow grants pull-requests: write on all triggers, including push,
where it's not needed.

Task 8.1: Condition pull-requests: write on event type

What: The auths-verify-commits.yml workflow grants
pull-requests: write at job level for all triggers. On push events,
this is unnecessary and expands the token's privilege surface.

Why: A reviewer correctly pointed out this is the same class of
over-permissioning that contributed to the original attacks. The Auths
action only uses pull-requests: write when post-pr-comment: true
AND the trigger is a pull_request event.

Recommendation for the GitHub Action itself:

File to modify:
/Users/bordumb/workspace/repositories/auths-base/auths-verify-github-action/src/main.ts

The action should skip the PR comment step (and not require the token)
when the event is not a pull_request. Currently the action may already
do this, but the workflow template should make it explicit by splitting
into two jobs or using conditional permissions:

Recommended workflow pattern for consumers:

jobs:
  verify:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: ${{ github.event_name == 'pull_request' && 'write' || 'none' }}

File to also update (action README / examples):
/Users/bordumb/workspace/repositories/auths-base/auths-verify-github-action/README.md

Update all example workflows to use conditional permissions.

Task 8.2: Action should warn when post-pr-comment is true on non-PR events

What: If a user configures post-pr-comment: true but the action
runs on a push event, the action should log a warning rather than
silently skipping or failing.

File to modify:
/Users/bordumb/workspace/repositories/auths-base/auths-verify-github-action/src/main.ts

if (postPrComment && github.context.eventName !== 'pull_request') {
  core.warning(
    'post-pr-comment is enabled but this is not a pull_request event. ' +
    'PR comment will be skipped. Consider conditioning pull-requests: write ' +
    'permission on the event type.'
  )
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions