Pester module warning 'CN=Jakub Jareš, O=Jakub Jareš, L=Praha, C=CZ'

[Acenl12]

Checklist

• Issue has a meaningful title
• I have searched the existing issues. See all issues
• I have tested using the latest version of Pester. See Installation and update guide.

What is the issue?

WARNING: Module 'Pester' version '3.4.0' published by 'CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US' will be superceded by version '5.5.0' published by 'CN=Jakub Jareš, O=Jakub Jareš, L=Praha, C=CZ'. If you do not trust the new publisher, uninstall the module.

Expected Behavior

Not seeing this warming

Steps To Reproduce

Install-Module AutomatedLab -Force

Describe your environment

Pester version     : 5.5.0 C:\Users\username\Documents\PowerShell\Modules\Pester\5.5.0\Pester.psm1
PowerShell version : 7.3.6
OS version         : Microsoft Windows NT 10.0.22621.0

Possible Solution?

?

[fflaten]

@nohwnd Wasn't this resolved?

[Acenl12]

By the way, I consider this also also as a security issue, powershell modules should not be signed by indivuduals.

[ay-azara]

Just downloaded the nupkg of Pester v5.5.0 from the PSGallery and looked at the Digital Signature for the DLLs. They are still using the certificate Acenl12 reported.

[fflaten]

Just downloaded the nupkg of Pester v5.5.0 from the PSGallery and looked at the Digital Signature for the DLLs. They are still using the certificate Acenl12 reported.

The certificate with subject Jakub Jareš is the expected certificate.

The warning while installing the module is what I believe should've been resolved.

[ay-azara]

Just downloaded the nupkg of Pester v5.5.0 from the PSGallery and looked at the Digital Signature for the DLLs. They are still using the certificate Acenl12 reported.

The certificate with subject Jakub Jareš is the expected certificate.

The warning while installing the module is what I believe should've been resolved.

Ah, my mistake. I think the fixed warning might have been the one that appeared when -SkipPublisherCheck wasn't given to Install-Module. Since the binaries have the expected certificate the warning here seems reasonable, as the Publisher is different from the previous one (Microsoft) and indicates a change of ownership (which may not be expected or desirable). Actually, the odd thing is that they didn't put that kind of change behind a -confirm flag.

[fflaten]

Yeah that's it, but I believe it was fixed somehow. At one point we changed the README from a warning to this because it just worked. 🙂

📦🔐 Pester is now signed. -SkipPublisherCheck should no longer be used to install from PowerShell Gallery on Windows 10

[nohwnd]

By the way, I consider this also also as a security issue, powershell modules should not be signed by indivuduals.

Unless we become a registered company I can't get a certificate for Pester specifically AFAIK, and such certificate would be pretty expensive. There is also technically no difference between a certificate for my name, and certificate for a company, other than if I drop from this project others can take over more easily.

I don't think this is a security incident, most other modules come unsigned, and they can change ownership or be tampered with without your knowledge. So if anything we are getting punished here for doing the right thing.

Yeah that's it, but I believe it was fixed somehow.

I believe there was a check in PowerShellGet that was specific to Pester to suppress this issue. @ay-azara which version of PowerShellGet are you using?

FWIW you can uninstall the old Pester from the system using this script: https://gist.github.com/nohwnd/5c07fe62c861ee563f69c9ee1f7c9688 and then there is no change of ownership.

[ay-azara]

@nohwnd I'm using Pester v5.5.0 and have PowershellGet 2.2.5 & 1.0.0.1. Pester v3.4.0 is still installed. Maybe I was still using 1.0.0.1 by accident when I installed?

[Acenl12]

By the way, I consider this also also as a security issue, powershell modules should not be signed by indivuduals.

Unless we become a registered company I can't get a certificate for Pester specifically AFAIK, and such certificate would be pretty expensive. There is also technically no difference between a certificate for my name, and certificate for a company, other than if I drop from this project others can take over more easily.

I don't think this is a security incident, most other modules come unsigned, and they can change ownership or be tampered with without your knowledge. So if anything we are getting punished here for doing the right thing.

Yeah that's it, but I believe it was fixed somehow.

I believe there was a check in PowerShellGet that was specific to Pester to suppress this issue. @ay-azara which version of PowerShellGet are you using?

FWIW you can uninstall the old Pester from the system using this script: https://gist.github.com/nohwnd/5c07fe62c861ee563f69c9ee1f7c9688 and then there is no change of ownership.

When I see a certificate like that as a security engineer, I could think it's a self signed cert of a threat actor,and block it using WDAC. I'm not blaming you guys, don't feel attacked. Im just concerned that if a PowerShell module use a certificate with a personal name in it. Pester has become such a core module in PowerShell and so widely used that's it not acceptable for me. In my environment i already blocked this certificate and the module until it gets improved

[fflaten]

I'm not blaming you guys, don't feel attacked.

🙂 Similarly any comments below are not meant as a personal attack, just interested in the topic.

When I see a certificate like that as a security engineer, I could think it's a self signed cert of a threat actor, and block it using WDAC. I'm not blaming you guys, don't feel attacked.

You could but it's not how the process works. A self signed certificate has the same subject and issuer. Our certificate is issued after strict identity verification by a reputable certificate authority included in Microsoft's trusted root program. It's trusted just the same as github.com's certificate. As long as the subject (publisher) is who you except for the software, something we've verified here, there's nothing wrong.

If we used a self-signed certificate you would get errors like this because the certificate chain did not start from a trusted root certificate in your certificate store:

Install-Module pester -Repository demo -Scope CurrentUser -Force

PackageManagement\Install-Package : The module 'Pester' cannot be installed or updated because the authenticode signature of the file 'Pester.psd1' is not valid.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21
+ ...          $null = PackageManagement\Install-Package @PSBoundParameters
+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
    + FullyQualifiedErrorId : InvalidAuthenticodeSignature,ValidateAndGet-AuthenticodeSignature,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

# or during import with AllSigned execution policy:
C:\Temp\5.5.0\Pester.Format.ps1xml: The file was skipped because of the following validation exception: File C:\Temp\5.5.0\Pester.Format.ps1xml cannot be loaded. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

In my environment i already blocked this certificate and the module until it gets improved

That's your choice and absolutely fine, but I wouldn't except any changes in the near future.

For now you can review, build and deploy the code unsigned if you need. You could even resign it with a internal certificate as part of a security review process. I wouldn't recommend adding the complexity just because you/company prefers vague organization names like "DOTPDN LLC" (Paint.Net) over the name of a personally identifiable long-term public maintainer. Just my two cents, so feel free to ignore.

[nohwnd]

I also want to echo that I don't feel attacked in any way, and am hoping that my comment did not sound overly aggressive. 😊

@fflaten thanks for responding here, I would not be able to put it better.

[nohwnd]

The module is signed by me, the certificate is trusted by digicert, and the warning can be either ignored or the older module uninstalled by the script provided.

@fflaten I can see reference to Pester and PSReadline whitelisting here https://github.com/PowerShell/PowerShellGetv2/blob/master/src/PowerShellGet/PowerShellGet.psd1#L199

https://grep.app/search?q=WhitelistedModules&filter[repo][0]=PowerShell/PowerShellGetv2 The code still seems to be in master on v2.

[fflaten]

@fflaten I can see reference to Pester and PSReadline whitelisting here https://github.com/PowerShell/PowerShellGetv2/blob/master/src/PowerShellGet/PowerShellGet.psd1#L199

https://grep.app/search?q=WhitelistedModules&filter[repo][0]=PowerShell/PowerShellGetv2 The code still seems to be in master on v2.

Thanks. I thought it was more fancy tbh 😁 In PSResourceGet (v3) I believe they removed the publisher check by default. So should be good going forward.

[nohwnd]

I thought it was more fancy tbh 😁

Yeah same.