{"version":"2.1.232","anchor":"windows-approved-commands-that-hide-shell-code-or-that-are-t","canonical_anchor":"windows-approved-commands-that-hide-shell-code-or-that-are-t","heading":"Windows: approved commands that hide shell code, or that are too long to analyze, get asked again","tier":"notice","area":"Windows","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232\/e\/windows-approved-commands-that-hide-shell-code-or-that-are-t","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232","markdown":"### Windows: approved commands that hide shell code, or that are too long to analyze, get asked again\n\nOn Windows, previously approved commands that wrap a shell, run long or use many redirects get asked again.\n\n**What**\n\nAlso on Windows only, a previously-approved command is bumped back to an approval prompt when its first word is a shell such as `bash`, `sh`, `zsh`, `dash`, `ksh`, `mksh` or `busybox`, because the security scan cannot see into the code that shell will run from a string. Over-long commands and commands packed with redirects are re-asked for the same reason.\n\n**Details**\n\n- Message shown: `This previously-approved command runs shell code from a string its security scan cannot see into; on Windows its writes cannot be checked for Cygwin symlink redirection and need human review.`\n- New pattern matching pulls redirect targets (`<`, `>`, `>>`, `&>`, `>|`, `>&`) straight out of raw command text when the command could not be parsed into a syntax tree.\n- Existing interpreter sets still apply; the shell list above is new.\n- The `cd`-compound case gets its own separate explanation.\n\n**Evidence**\n\n`This previously-approved command runs shell code from a string its security scan cannot see into; on Windows its writes cannot be checked for Cygwin symlink redirection and need human review.`\n\n- Area: Windows\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}