--list-tasks renders resolved values and masks nothing. commands/apply.go returns from the listing branch before AddGlobalSensitive(CollectPlaySensitiveValues(...)) runs, so the global masker is empty by construction, and neither the human path nor emitListJSON calls MaskString. This is documented rather than accidental: docs/json-output.md and docs/ansible-dokku.md both tell the reader never to route that stream anywhere a secret must not land.
#427 widened what lands in it. A task with no name: is now named after the resource it addresses, so its name embeds its identity field values. TestIdentityKeysAreNeverSensitive keeps any field tagged sensitive:"true" out of an address, so a task-declared secret never reaches a name - but an input declared sensitive: true interpolated into an identity field still does, in the clear.
The question is whether the listing should mask. Arguments in both directions: the stream exists so a user can see the plan that will run, and *** in place of a resolved app name makes it less useful for that; against, a flag whose output cannot be shown to anyone is a trap, and the masking machinery is already built.
If masking wins, the change is to move the AddGlobalSensitive call above the --list-tasks return in commands/apply.go and route the listing's name / when / loop_item through MaskString, then update both docs. Note the interaction recorded in docs/json-output.md: MaskString is substring replacement, so a short sensitive value can mask two distinct task names into the same string, which would cost the listing the correlation property the run stream has.
--list-tasksrenders resolved values and masks nothing.commands/apply.goreturns from the listing branch beforeAddGlobalSensitive(CollectPlaySensitiveValues(...))runs, so the global masker is empty by construction, and neither the human path noremitListJSONcallsMaskString. This is documented rather than accidental:docs/json-output.mdanddocs/ansible-dokku.mdboth tell the reader never to route that stream anywhere a secret must not land.#427 widened what lands in it. A task with no
name:is now named after the resource it addresses, so its name embeds its identity field values.TestIdentityKeysAreNeverSensitivekeeps any field taggedsensitive:"true"out of an address, so a task-declared secret never reaches a name - but an input declaredsensitive: trueinterpolated into an identity field still does, in the clear.The question is whether the listing should mask. Arguments in both directions: the stream exists so a user can see the plan that will run, and
***in place of a resolved app name makes it less useful for that; against, a flag whose output cannot be shown to anyone is a trap, and the masking machinery is already built.If masking wins, the change is to move the
AddGlobalSensitivecall above the--list-tasksreturn incommands/apply.goand route the listing'sname/when/loop_itemthroughMaskString, then update both docs. Note the interaction recorded indocs/json-output.md:MaskStringis substring replacement, so a short sensitive value can mask two distinct task names into the same string, which would cost the listing the correlation property the run stream has.