Powershell: *.format.ps1xml not work with "Receive-Job"

[isra-fel]

Description

This is from Azure PowerShell team. Our cmdlet Set-AzKeyVaultSecret relies on *.format.ps1xml to hide some sensitive properties, including the secret in plain text.

However when excuting in a job, like in this issue Azure/azure-powershell/issues/12266 , the format rules somehow do not apply, and the secret text would appear.

Steps to reproduce

See Azure/azure-powershell/issues/12266

Expected behavior

Format rules should apply no matter the cmdlet is run in or not in a job.

Actual behavior

Format rules do not apply. Plain text secret displayed.

See Azure/azure-powershell/issues/12266

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.19041.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PowerShell core reproduces this issue too --

Name                           Value
----                           -----
PSVersion                      7.0.2
PSEdition                      Core
GitCommitId                    7.0.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[isra-fel]

Found this post saying "PowerShell adds extra properties to all objects received from job", and I guess the output type also changes, that's why the formats do not work.
If that's the case, is there a way to fix the display?

[vexx32]

Looking at the linked issue... they're using Start-Job which invokes the script in a different process entirely. Objects received from there have to be deserialized, which will mean that any defined formats will not apply to the received objects; they're essentially re-created as PSCustomObject with an additional PSTypeName of Deserialized.Original.Type.Name

While it's unfortunate in this particular case, I'm not sure this is necessarily avoidable. The best thing I can think to do here is to flag sensitive properties as hidden, perhaps using System.Management.Automation.HiddenAttribute? 🤔

[SeeminglyScience]

Can you provide a link to the format file for this object?

Found this post saying "PowerShell adds extra properties to all objects received from job", and I guess the output type also changes, that's why the formats do not work.

Output objects are serialized and deserialized into custom psobjects, but generally speaking formatting will still apply. I haven't been able to reproduce the problem with any of the built in formatting rules or any of my custom formatting files.

[vexx32]

Good to know! I must be remembering something else, then, maybe an edge case where it wasn't working properly for whatever reason.

@isra-fel after tinkering around a little it seems to me the most likely source of the issue is that the user doesn't have your module actually imported in the parent session, and it's only imported for the child job. As a result, the format information is missing from the parent session.

That's not something we can really do anything about necessarily, and is probably one of the reasons I'd really question why a _format_ file is being used to hide supposedly sensitive information? Custom formats are a UX and convenience feature, not a security feature. If the data is potentially sensitive, it should probably be hidden in a way that doesn't depend on a format file.

[isra-fel]

Thank you @vexx32 and @SeeminglyScience for your quick and helpful response!

The situation is just like you said, the module was not loaded in the parent session. If I import the module in advance and the problem would be gone.

Agree with @vexx32 's point. We need to revisit our design.

Thanks again. This issue can be closed :)