Skip to content

Destructive-command scan cannot see aliases defined in the user's own ~/.gitconfig #516

Description

@emal-avala

Remaining seam identified during the #506 review cycle, deliberately left out of scope there.

The destructive-command guard analyses command text: it now resolves git aliases reached through -c, --config-env, GIT_CONFIG_*, config files and includes, and treats anything it cannot fully resolve as unanalysable (warning path). But an alias defined in the user's pre-existing ~/.gitconfig — e.g. [alias] nuke = !rm -rf — is invisible to a static scan of the invocation, so git nuke is covered only by the raw-text scans.

Closing it would require resolving git configuration at validation time (reading the effective config), which is a different design than the current text-analysis gate and was deliberately not added.

Options to evaluate:

  • resolve git config --get alias.<name> at validation time for alias-shaped invocations (cost: subprocess per check, must itself be sandboxed/timeboxed)
  • warn once per session when !-form aliases exist in the effective config
  • accept as documented residual risk (the user authored their own gitconfig)

Context: crates/lib/src/tools/bash/bash_security.rs, crates/lib/src/tools/bash_parse.rs.

Activity

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions