Description

James O'Neill (jhoneill)

opened on May 5, 2022

Issue body actions

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Set-ExecutionPolicy to Allsigned, restart PowerShell, run get-module -listavailable.

Start VSCode with may 2022 PowerShell extension,

Expected behavior

PowerShell starts, loading PS Readline. Get-Module lists available modules

Actual behavior

On loading PowerShell reports untrusted signatures for Psreadline.format.xml and PSReadline.psm1 (but not .PSD1)

Get-Module reports untrusted signatures for every signed CDXML file (but not their associated PSD1), but reports no errors where files are unsigned. 

Loading VSCode the PowerShell Integrated console reports untrusted signatures for the PS1, types.ps1.xml and .PSM1 files for PowerShell editor services (but not their PSD1 nor files in PSReadline).

Error details

No error

Environment data

�[32;1mName                           Value�[0m
�[32;1m----                           -----�[0m
PSVersion                      7.2.3
PSEdition                      Core
GitCommitId                    7.2.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

Activity

1. James O'Neill (jhoneill)

   added

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on May 5, 2022
2. jhoneill commented on May 5, 2022

   

   James O'Neill (jhoneill)

   on May 5, 2022

   Author

   More actions

   Not sure if this a bug, or just strange behaviour. But I've applied 7.2.3 and the update extension for VSCode in the last couple of days and also been in discussions about policy and signing.

   It appears that when starting the shell (outside VSCode) , the .PSD1 for PSReadline is trusted enough to try to load the format and PSM1 files, which are signed with the same cert but loading them wants some assurance the cert can be trusted.

   The same applies to all the CIM cmdlets inherited from PS5 the PSD1 and CDXML files are signed with the same cert but the CDXML files aren't trusted for example if I run Get-Printer (V5 CIM cmdlet) in V7.2.3 I get prompted to approve the CDXML files to load the module. But the autoloading mechanism has read the printmanagement module's PSD1 file which is signed with the same cert, and figured out that is the module which delivers Get-Printer, and the CDXML files to be loaded and never asked me to approve the module as a whole, just those component files.

   It looks like some certs are trusted for some file types and not others. The behaviour is unexpected, but may be by design. If anyone can shed any light...
3. James O'Neill (jhoneill)

   changed the title [-]Certificate and execution policy strange newss[/-] [+]Certificate and execution policy strangeness[/+] on May 5, 2022
4. daxian-dbw commented on May 5, 2022

   

   Dongbo Wang (daxian-dbw)

   on May 5, 2022

   Member

   More actions

   It appears that when starting the shell (outside VSCode) , the .PSD1 for PSReadline is trusted enough to try to load the format and PSM1 files, which are signed with the same cert but loading them wants some assurance the cert can be trusted.

   This is like due to a performance optimization: skip AMSI and suspicious code scan for the .psd1 file that contains a safe HashtableAst only (done in #8341). See the code at https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/runtime/CompiledScriptBlock.cs#L206

   VSCode cannot present you the same prompt and thus throws the error instead. I think that's determined by how PSReadLine gets loaded by VSCode. Andy Jordan (@andschwa) may be able to share more details on that part.
5. daxian-dbw commented on May 9, 2022

   

   Dongbo Wang (daxian-dbw)

   on May 9, 2022

   Member

   More actions

   Given that the performance optimization is by design, I will mark this issue as Resolved - By Design.
6. Dongbo Wang (daxian-dbw)

   added

   Resolution-By DesignThe reported behavior is by design.The reported behavior is by design.

   on May 9, 2022
7. jhoneill commented on May 9, 2022

   

   James O'Neill (jhoneill)

   on May 9, 2022

   Author

   More actions

   Dongbo Wang (@daxian-dbw) Yes, that's fine. I think there is an issue with some things (e.g. PSReadline) being delivered signed but not trusted, but I'll get my facts right first, and open a specific issue for that.

   Reacted by Dongbo Wang
9. ghost closed this as completedon May 10, 2022

Issue actions