Use CommandInfo within Command.CreateCommandProcessor() if available.#27674
Open
mjr4077au wants to merge 1 commit into
Open
Use CommandInfo within Command.CreateCommandProcessor() if available.#27674mjr4077au wants to merge 1 commit into
CommandInfo within Command.CreateCommandProcessor() if available.#27674mjr4077au wants to merge 1 commit into
Conversation
…ble. During testing of `PowerShell.GetSteppablePipeline()`, I found that I could not reference internal-scoped cmdlets of my module despite providing a proper CmdletInfo object to `PowerShell.AddCommand()`. Further review found that `Command.CreateCommandProcessor()` is eschewing the `CommandInfo` object it has a hold of for the text representing the command instead. This PR tests whether `Command.CommandInfo` is null and if not, uses the `CommandInfo` overload of `CommandDiscovery.LookupCommandProcessor()` instead, which not only addresses this problem, but also addresses what I consider to be a security concern where I might be explicitly using a `CommandInfo` object of a trusted command to not be subject to command/function re-definition.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates Command.CreateCommandProcessor() to prefer an existing CommandInfo instance (when available) instead of re-resolving by CommandText, improving correctness for scenarios like PowerShell.AddCommand(CmdletInfo).GetSteppablePipeline() where the provided CmdletInfo should be authoritative.
Changes:
- Use the
CommandDiscovery.LookupCommandProcessor(CommandInfo, ...)overload whenCommand.CommandInfois present. - Continue using the
CommandText-based lookup as a fallback whenCommandInfois not available.
Comment on lines
+530
to
+533
| // Favour a ComamndInfo object if one is available. | ||
| commandProcessorBase = CommandInfo is CommandInfo commandInfo | ||
| ? executionContext.CommandDiscovery.LookupCommandProcessor(commandInfo, origin, _useLocalScope, null) | ||
| : executionContext.CommandDiscovery.LookupCommandProcessor(CommandText, origin, _useLocalScope); |
Author
There was a problem hiding this comment.
I'll need a team member with more knowledge of the engine than I have to advise whether this suggestion has valid merit or not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Summary
Use
CommandInfowithinCommand.CreateCommandProcessor()if available.PR Context
During testing of
PowerShell.GetSteppablePipeline(), I found that I could not reference internal-scoped cmdlets of my module despite providing a properCmdletInfoobject toPowerShell.AddCommand(). Further review found thatCommand.CreateCommandProcessor()is eschewing theCommandInfoobject it has a hold of for the text representing the command instead.This PR tests whether
Command.CommandInfois null and if not, uses theCommandInfooverload ofCommandDiscovery.LookupCommandProcessor()instead, which not only addresses this problem, but also addresses what I consider to be a security concern where I might be explicitly using aCommandInfoobject of a trusted command to not be subject to command/function re-definition.Test function for validation of this PR before/after:
Before:
After:
This is also my first PR to the project so if I've done anything wrong, just let me know and I'll get it fixed up.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header