PSPKI icon indicating copy to clipboard operation
PSPKI copied to clipboard

improve `import-module pspki` loading time

Open iRon7 opened this issue 2 years ago • 2 comments

Not sure whether this is a valid request but trying it anyway 😀. We are noticing quiet some loading time for import-module pspki in our environment. Currently it is 12 seconds but probably higher when there is more network traffic (Windows PowerShell). As far as I can determine it is related to all the separate signed PowerShell scripts Dot sourcing a single script as e.g. . .\Get-CertificateRequest.ps1 takes about 3 seconds. While dot sourcing the same script without the signature block loads instantly (al testing done in new sessions). Also setting the Execution Policy to Bypass will more than halve the loading time. It is in my believe that adding all the separately signed PowerShell script to a single script (or even the module) itself, will improve the loading time of this module. This is also suggested here Digitally signed manifest module slow to import: "The best solution at the moment is to "compile" the ps1 files into a single psm1 as a build step."

Is it possible to investigate/implement this PSPKI module?

$PSVersionTable

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

iRon7 avatar Jun 15 '22 14:06 iRon7

you are right, the delay is caused by signature validation routine, which builds the chain and contact internet to get revocation info from public CA. However, this should not be a problem since all scripts are signed with same certificate and you have to download this revocation info only once. It is then cached and all subsequent scripts will be validated against cached info. However, multiple attempts can be done if revocation info cannot be accessed. I would check if your firewall allows connections to revocation information (OCSP and CRLs).

Putting all scripts into single file is not possible, because it is impossible to maintain this amount of code in a single file.

Crypt32 avatar Jun 15 '22 15:06 Crypt32

Crypt32, Thanks for the answer.

It is then cached and all subsequent scripts will be validated against cached info

Yes, there is indeed a difference between the first and the following scripts but there is apparently also some (local) overhead in checking the rest where loading (dot sourcing one script) takes 3 seconds and loading the whole module takes 12 second (4 times as long).

However, multiple attempts can be done if revocation info cannot be accessed.

This is indeed likely the case as there is no access in our environment to the outside world.

Putting all scripts into single file is not possible, because it is impossible to maintain this amount of code in a single file.

This could technically be a part of an automated publishing process, but I do understand if you do not want to go into this.

iRon7 avatar Jun 15 '22 15:06 iRon7