Sensitive variable value causes unrelated substrings (e.g. filenames) to be redacted in build output

[smabkhout]

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 a sensitive variable's value happens to also be a substring of unrelated, non-secret text elsewhere in the build output (for example, a filename), Packer's redaction logic replaces every occurrence of that substring with <sensitive>, regardless of context.

In my case, ssh_username is set to "ubuntu" and marked sensitive = true. Because "ubuntu" is also part of the ISO filename (ubuntu-22.04.5-live-server-amd64.iso), Packer redacts the filename too, even though it has nothing to do with the actual secret value. This is also true for the VM name and other unrelated strings.

This raises a question about intended behavior: should redaction be scoped to only the variable's own output context, rather than a blind substring replace across all log output? As implemented, a reader can often infer what the redacted substring must be from surrounding context (e.g. "this looks like it should say a known Ubuntu ISO filename, so the sensitive value must be 'ubuntu'"), which seems to undermine the purpose of marking the variable sensitive in the first place. Is this considered expected/working-as-intended behavior, or would a more context-aware redaction approach be welcomed as a fix?

Reproduction Steps

1. Define a sensitive variable whose value is a short, common substring that's also likely to appear elsewhere in build output (e.g. "ubuntu").
2. Reference an ISO or any file whose name also happens to contain that same substring.
3. Run packer build.
4. Observe that the filename in the log output is partially redacted, even though it is not the sensitive value itself.

Packer version

Packer v1.15.3

Simplified Packer Template

variable "iso_path" {
  type = string
}

variable "iso_checksum" {
  type = string
}

variable "ssh_username" {
  type      = string
  default   = "ubuntu"
  sensitive = true
}

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

source "qemu" "ubuntu2204" {
  iso_url      = var.iso_path
  iso_checksum = "sha256:${var.iso_checksum}"
  ssh_username = var.ssh_username
  ssh_password = var.ssh_password
  format       = "qcow2"
  accelerator  = "none"
}

build {
  sources = ["source.qemu.ubuntu2204"]
}

Operating system and Environment details

Build machine: Ubuntu Server (VM, no nested virtualization/KVM available)
Architecture: x86_64

Log Fragments and crash.log files

qemu.<sensitive>2204: output will be in this color.

==> qemu.<sensitive>2204: Retrieving ISO
==> qemu.<sensitive>2204: Trying ../../artifacts/<sensitive>-22.04.5-live-server-amd64.iso
==> qemu.<sensitive>2204: Trying ../../artifacts/<sensitive>-22.04.5-live-server-amd64.iso?checksum=sha256%3A9bc6028870aef3f74f4e16b900008179e78b130e6b0b9a140635434a46aa98b0

Note that ubuntu-22.04.5-live-server-amd64.iso is a filename, not a secret — it is only being redacted because it contains the same substring as the sensitive ssh_username value ("ubuntu")

[krusta07]

This is a really interesting edge case where naive substring replacement accidentally hurts security by creating easily inferable masks. I'd love to look into the logging/redaction pipeline and explore a more context-aware approach or boundary-checked filtering to prevent false positives on common strings like filenames. Mind assigning this to me

[smabkhout]

Thanks for you interest. I am not a maintainer of this project, so I can't assign issues.

[tanmay-hc]

@krusta07 Feel free to take up this issue and create a PR, and I will review. Follow the contributions guidelines.

[apoorva-01]

Dug into this. The redaction lives in the SDK, not Packer core: LogSecretFilter in packer/logs.go just runs strings.Replace(line, secret, "<sensitive>", -1) for every secret, so it swaps the value out everywhere it shows up.

Problem is you can't fix this in the text. The secret is ubuntu and so is the ubuntu in the ISO filename. Same bytes. A word-boundary check doesn't help (the filename one is still boundary-flanked) and it'd stop hiding real secrets buried in URLs.

According to me - only real fix is redacting the value where it's actually printed, not globally, which is a bigger change and lives in the SDK. So which way do you want it, keep it as-is or go context-scoped?

@tanmay-hc happy to help on the SDK side if it's the latter.

[tanmay-hc]

@apoorva-01 The real problem is that we also redact strings we don't control. For instance, an error message emitted by a provisioner may contain the sensitive value, and at that point we can't tell whether it came from the variable or is just an unrelated substring. A context-scoped approach that only redacts at the variable's own print site wouldn't catch those cases. I take the point that an over-redacted filename can let a reader infer the secret, but I'd still rather have some false positives here than risk actually exposing a sensitive value. So I'd lean toward keeping the blanket replacement rather than narrowing it.
But in case you had another approach in mind, I'd love to see a PR for the same.