question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

AvoidUsingPlainTextForPassword docs do not cover all checked parameter names

See original GitHub issue

I have a script parameter that holds a path to the encrypted credential file named $CredentialFile for which I get the warning:

Parameter ‘$CredentialFile’ should use SecureString, otherwise this will expose sensitive information. See ConvertTo-SecureString for more information.

There is no reason for me use SecureString here and I cannot think of a better alternative to the parameter name, so it would be nice to suppress this message for this particular instance, but not to the whole file or project. Besides, the documentation for PSAvoidUsingPlainTextForPassword needs to include Credential and whatever other strings it gets triggered of, since it only mentions one word: Password.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
rjmholtcommented, Aug 6, 2020

Addressing your title, see https://github.com/PowerShell/PSScriptAnalyzer#suppressing-rules.

Besides, the documentation for PSAvoidUsingPlainTextForPassword needs to include Credential and whatever other strings it gets triggered of, since it only mentions one word: Password.

Agreed.

It seems the list of terms is:

https://github.com/PowerShell/PSScriptAnalyzer/blob/c78f5a60c1f49a5e767286ff6323a2ec0788991a/Rules/AvoidUsingPlainTextForPassword.cs#L34

And those terms only need to appear within the parameter/variable name to trigger the rule:

https://github.com/PowerShell/PSScriptAnalyzer/blob/c78f5a60c1f49a5e767286ff6323a2ec0788991a/Rules/AvoidUsingPlainTextForPassword.cs#L45

We would welcome your PR to update the docs here

0reactions
rjmholtcommented, Aug 25, 2021

Is there any movement on this?

Not yet; we would welcome your contribution.

Does anyone have any suggestions for how this should be reimplemented?

Ultimately this is a very heuristic rule and the idea is we can infer what should be a secure string based on the name of parameters. But most users seem to appreciate that. I think a regex is probably the way to go. Something like:

([Cc]redential|[Pp]ass(word|phrase)|[Tt]oken)$
Read more comments on GitHub >

github_iconTop Results From Across the Web

Using PSScriptAnalyzer - PowerShell
This article describes various features of PSScriptAnalyzer and how to use them.
Read more >
AvoidUsingPlainTextForPassword - PowerShell
Passwords should be stored in the SecureString type. The following parameters are considered password parameters (this is not case sensitive):.
Read more >
What are these parameter name annotations in my VS ...
3 Answers 3 · none — Disable parameter inlay hints. · literals — Only show inlay hints for literals (string, number, Boolean). ·...
Read more >
Problems with interconnected parameters in PowerShell ...
If I use no switches at all, it prompts me for a Name then sets all options to $True. The first problem is...
Read more >
Erklärung des Begriffs: PowerShell Script Analyzer (PSSA)
Generally this is a red flag that a variable is not needed. This rule does not check if the assignment and usage are...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found