-
Notifications
You must be signed in to change notification settings - Fork 0
first verison #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2e57deb759
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| $storeDir = Split-Path $storePath -Parent | ||
| if (-not (Test-Path $storeDir)) { | ||
| New-Item -Path $storeDir -ItemType Directory -Force | Out-Null | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Handle relative SCRIPT_WHITELIST_GUARD_STORE paths
If a user sets SCRIPT_WHITELIST_GUARD_STORE to a relative path or bare filename (a reasonable customization), Split-Path -Parent returns an empty string and New-Item -Path $storeDir fails, which makes Set-WhitelistData return $false and prevents any whitelist from being saved. The guard then silently can’t persist entries in that configuration. This only occurs when the env var points to a relative path or filename (not an absolute path).
Useful? React with 👍 / 👎.
| # Early return if no command or no command name | ||
| if (-not $commandAst -or -not ($commandName = $commandAst.GetCommandName())) { | ||
| [Microsoft.PowerShell.PSConsoleReadLine]::AcceptLine() | ||
| return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don’t skip scripts invoked via call operator
The handler exits whenever GetCommandName() returns null, which happens for common forms like & "C:\Path With Spaces\script.ps1" or other dynamic/quoted invocations. In those cases the guard accepts the line without any whitelist check, so interactive script execution is unguarded whenever users rely on the call operator. This only impacts invocations where the command name is not a bare token.
Useful? React with 👍 / 👎.
| $ast = [System.Management.Automation.Language.Parser]::ParseInput($line, [ref]$null, [ref]$null) | ||
| $commandAst = $ast.FindAll({ | ||
| param($node) | ||
| $node -is [System.Management.Automation.Language.CommandAst] | ||
| }, $false) | Select-Object -First 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only first command in a line is checked
The handler selects the first CommandAst and ignores the rest of the line, so Get-Process; .\script.ps1 (or any script after ;/&&) will run without whitelist validation. This is a functional gap whenever users chain commands on a single line, because only the first command is inspected.
Useful? React with 👍 / 👎.
No description provided.