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.

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