This does not look correct. This appears to be taking a str of potentially multiple arguments and passing it as just the first argument.

Also the docstring only states that a str is even supported and not a list/tuple

:param str args: String of command line args to pass to the script. Only
        used if no args are specified as part of the `name` argument. To pass a
string containing spaces in YAML, you will need to doubly-quote it.

Thanks. This should be fixed with https://github.com/saltstack/salt/pull/68301/files#diff-700b7d75700c9eafa3ee48d01236e59f37b2ed81d998267136fbcc0224766497R3007 , althrough passing multiple arguments with a single string might be unreliable, especially on Windows.

Nice. Thanks. I think these improvements are nice. It bothered me since starting to use salt that you could not pass lists like you could with the subprocess module to avoid escaping issues.

@xsmile Assume C:\temp\test.ps1 with the following content:

[CmdLetBinding()]
Param([SecureString] $SecureString)
$Credential = New-Object System.Net.NetworkCredential("DummyId", $SecureString)
$Credential.Password

As noted in the comments, using -File does not work:

PS C:\src> powershell.exe -File C:\Temp\test.ps1 -SecureString (ConvertTo-SecureString -String "I like cheese" -AsPlainText -Force) -ErrorAction Stop

You must use -Command to evaluate powershell commands in arguments to a script:

PS C:\src> powershell.exe -Command "& { C:\Temp\test.ps1 -SecureString (ConvertTo-SecureString -String 'I like cheese' -AsPlainText -Force) -ErrorAction Stop }"

@twangboy I would argue that by using -Command you are not directly executing a script but running a PowerShell command executing a script. This introduces issues like the need to carefully handle special characters, which is an impossible task since user input is not known in advance. Parameters can be evaluated as code, allowing for code injection without the need to know the script content.

IMHO the proper way to handle SecureString would be to use a dedicated module that takes care of encrypting such parameters and passing them to the final script.

Running PS C:\src> powershell.exe -Command "& { C:\Temp\test.ps1 -SecureString (ConvertTo-SecureString -String 'I like cheese' -AsPlainText -Force) -ErrorAction Stop }" probably defeats the purpose of SecureString since the password will be visible in plain text on the command line and can be logged.

The password is just an example for evaluating powershell code as arguments. This was working before these changes. Now they aren't. If you can run it in a powershell prompt, you should be able to run it with Salt.