Eh, I wouldn't really call it "basic input validation", it's more like fuzzy presumptions of trustworthiness. You have one part of PowerShell team that is wary of deserializing ScriptBlocks into ScriptBlocks instead of strings because that could trivially lead to RCE; and then there is other part which sees nothing wrong with executing code with arbitrary semantics (e.g. Get-ItemProperty) on whatever strings are lying around in the blob.
The root of the problem is IMHO is having code with arbitrary semantics; it's undoubtedly quite handy to use but the price is the inherent uncertainty about the security implications. I mean, who is aware that if you feed Get-ItemProperty something that starts with two backslashes, then it will blindly send your credentials to whatever domain is written after those backslashes? Why is it even doing that? Oh, right, because that's how you make remote shares look like local directories.
I didn't mean to trivialize the issue. You describe a problem that arise when multiple parties share data with "presumptions of trustworthiness" i.e. do not perform proper input validation. No?
Well, I guess you can put it like that but I personally wouldn't call it "basic input validation", that would be something on the level "does this field really contains an integer?"
I don't think the problem is even the Get-ItemProperty itself, even though you'd probably want to use Select-Object instead wherever you can, but the fact that deserializer allows ridiculous PSPath values in the nested objects/properties; why does it do it? Is there no actual schema for e.g. Microsoft.Win32.RegistryKey type?
The thing I love about powershell is that you don't have to learn any DSLs, unlike bash, zsh, and the like. Want to manipulate some structured text data? Convert it to a native object, modify it using powershell syntax, and convert it back to the original data format. If you want to do this in bash, you have to learn the syntax and parameters for many utilities like jq, awk, starletxml, and many others. Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code, as is the case with bash/zsh. You can also easily create whole UI windows in PowerShell and do some other complicated things that are barely possible in bash. Some people complain that cmdlets are too long to write, but you can just write the first letters of each command, e.g. Get-ChildItem -> gci, and it will do the work. Also, everything is much more standardized than in bash, which makes it easier to learn the scripting language.
>you don't have to learn any DSLs, unlike bash, zsh, and the like.
I'm not sure I follow. Surely you need to learn PowerShell. What other DSL do you need to learn to use bash?
If you mean, for example, grep syntax: primary use case of a shell is running shell commands, you need to know regex to search using PowerShell too.
I agree that powershell is a better programming language than bash, but I don't really write programs in bash (or fish, which I primarily use). And for serious scripts I prefer Python anyway
>Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code,
Actually, unlike bash, you can't use the output of arbitrary command. In bash, everything is a text that you can prices generically, grep, less, tail, etc. Unlike in powershell.
Generally other DSLs are other applications you will need with bash to accomplish your goal like grep, curl, jq and others. For example, to hit a rest API, parse the response and then do something based on the response in bash would require curl, jq to properly handle it. Powershell wouldn't require that since Invoke-RestMethod would return dictionary that easily handled. Also, for applications that can return JSON like kubectl, it can easily turn those into objects with ConvertFrom-JSON
Think of Powershell as replacement for bash AND python with built in CLI library. You can run interactively to do little stuff but if you need heavier lifts that requires a script with prompts and all that, you got it.
I had the same problem initially. It's sometimes easier on the command line, since piping file and directory objects to commands generally binds their PSPath to LiteralPath using a parameter alias.
Wow, this is a Hyper-V breakout! I am amazed that it's 2024 and we still have problems with basic input validation.
Eh, I wouldn't really call it "basic input validation", it's more like fuzzy presumptions of trustworthiness. You have one part of PowerShell team that is wary of deserializing ScriptBlocks into ScriptBlocks instead of strings because that could trivially lead to RCE; and then there is other part which sees nothing wrong with executing code with arbitrary semantics (e.g. Get-ItemProperty) on whatever strings are lying around in the blob.
The root of the problem is IMHO is having code with arbitrary semantics; it's undoubtedly quite handy to use but the price is the inherent uncertainty about the security implications. I mean, who is aware that if you feed Get-ItemProperty something that starts with two backslashes, then it will blindly send your credentials to whatever domain is written after those backslashes? Why is it even doing that? Oh, right, because that's how you make remote shares look like local directories.
I didn't mean to trivialize the issue. You describe a problem that arise when multiple parties share data with "presumptions of trustworthiness" i.e. do not perform proper input validation. No?
Well, I guess you can put it like that but I personally wouldn't call it "basic input validation", that would be something on the level "does this field really contains an integer?"
I don't think the problem is even the Get-ItemProperty itself, even though you'd probably want to use Select-Object instead wherever you can, but the fact that deserializer allows ridiculous PSPath values in the nested objects/properties; why does it do it? Is there no actual schema for e.g. Microsoft.Win32.RegistryKey type?
> I am amazed that it's 2024 and we still have problems with basic input validation.
https://news.ycombinator.com/item?id=41392128 :rolling-eyes:
I envy your wonder. I predict amazement for decades to come.
The thing I love about powershell is that you don't have to learn any DSLs, unlike bash, zsh, and the like. Want to manipulate some structured text data? Convert it to a native object, modify it using powershell syntax, and convert it back to the original data format. If you want to do this in bash, you have to learn the syntax and parameters for many utilities like jq, awk, starletxml, and many others. Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code, as is the case with bash/zsh. You can also easily create whole UI windows in PowerShell and do some other complicated things that are barely possible in bash. Some people complain that cmdlets are too long to write, but you can just write the first letters of each command, e.g. Get-ChildItem -> gci, and it will do the work. Also, everything is much more standardized than in bash, which makes it easier to learn the scripting language.
>you don't have to learn any DSLs, unlike bash, zsh, and the like.
I'm not sure I follow. Surely you need to learn PowerShell. What other DSL do you need to learn to use bash?
If you mean, for example, grep syntax: primary use case of a shell is running shell commands, you need to know regex to search using PowerShell too.
I agree that powershell is a better programming language than bash, but I don't really write programs in bash (or fish, which I primarily use). And for serious scripts I prefer Python anyway
>Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code,
Actually, unlike bash, you can't use the output of arbitrary command. In bash, everything is a text that you can prices generically, grep, less, tail, etc. Unlike in powershell.
Generally other DSLs are other applications you will need with bash to accomplish your goal like grep, curl, jq and others. For example, to hit a rest API, parse the response and then do something based on the response in bash would require curl, jq to properly handle it. Powershell wouldn't require that since Invoke-RestMethod would return dictionary that easily handled. Also, for applications that can return JSON like kubectl, it can easily turn those into objects with ConvertFrom-JSON
Think of Powershell as replacement for bash AND python with built in CLI library. You can run interactively to do little stuff but if you need heavier lifts that requires a script with prompts and all that, you got it.
Nothing stopping you from using PowerShell like that with regular expressions and string manipulations like Select-String, Out-String, -Split.
It might compare favorably as a scripting language to bash, but I prefer python in this space.
As an interactive shell I'm getting used to powershell on Windows, but I have too much bash muscle memory for now.
My biggest frustration is remembering to use LiteralPath so filenames with [] in them don't cause trouble
I had the same problem initially. It's sometimes easier on the command line, since piping file and directory objects to commands generally binds their PSPath to LiteralPath using a parameter alias.
[flagged]