Sensitive variables are logged when escaped for powershell

[zinkj]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Overview of the Issue

When sensitive variables contain characters that require escaping the logs will print that sensitive variable in its escaped form.

Reproduction Steps

Run example from powershell with PACKER_LOG=1:

$Env:PACKER_LOG=1;& .\packer.exe build -var password="abc`$123" password.pkr.hcl

Packer version

Packer v1.10.2

Simplified Packer Template

variable "password" {
  type    = string
  sensitive = true
}

source "file" "basic-example" {
  content =  "Lorem ipsum dolor sit amet"
  target =  "dummy_artifact"
}

build {
  sources = ["sources.file.basic-example"]

  provisioner "powershell" {
    environment_vars = [
      "PASSWORD=${var.password}",
    ]
    inline = ["echo foo"]
  }
}

Operating system and Environment details

Windows Server 2022

Log Fragments and crash.log files

2024/04/12 10:11:48 packer.exe plugin: Env var <sensitive> converted to abc`$123 after escaping chars special to PS

Full Logs

[lbajolet-hashicorp]

Hi @zinkj,

Thanks for the report, looking at the problem however, I'm not sure we'll be able to offer a good solution with the current architecture regarding log filtering.

The way we do things re:sensitive variables is essentially by strings.Replace(sensitiveVariable, "<sensitive>", -1), which in effect if the variable gets escaped one way or another, won't match anymore.
We don't have agency on what gets printed by custom code, and it wouldn't be feasible to support every possible escaping scheme under the sun, therefore I'm not sure we have a good way to handle cases like these, at least without seriously rethinking/refactoring how this gets printed out.

I'll keep this issue open for now, but this seems like unlikely to happen in the short/medium term, sorry.