Closed potatoqualitee closed 5 years ago
If I remember correctly, it won’t help. The version of Pester shipped with windows is catalog signed by Microsoft. PowerShellGet would still complain if we sign new versions with a non-MS cert.
On Feb 24, 2018, at 3:57 PM, Chrissy LeMaire notifications@github.com wrote:
- Provide a general summary of the issue in the Title above
First, Pester is awesome and people are loving it. We created a framework around Pester with dbchecks and the reception has been very positive.
I saw #900 and know it's a known limitation but have a proposed solution below.
- Expected Behavior
Pester is catalog signed
4.Current Behavior
Pester is not catalog signed
- Possible Solution
DigiCert offers free Code Signing Certs for MVPs.
An alternative is to setup a Trade Name and sign it but if it's not under a personal name, DigiCert does charge. In order to ensure dbatools is signed under a trade name, I reached out and asked the community to help us purchase a code signing certificate. Two community members purchased a 3 year certificate for us.
- Context
We include Pester as a required module in dbachecks and have to explicitly say everywhere how to first update Pester the manual way.
Install-Module Pester -SkipCatalogCheck -Force
Even though we state this everywhere, we still get questions.
Also, we signed our module but realized it's not as useful if all required modules are not signed. I can get our other module, PSFramework, signed but won't pursue that avenue without Pester being signed.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Seems unlikely but I'm always hopeful - perhaps Microsoft would consider using your cert in future Windows releases.
After all, Microsoft has made exceptions for Pester in the past 😁
Pester has already been removed from PowerShell Core and @steveL-Msft has also thought of removing it from Windows PowerShell in 5.2 (although not sure what the final decision is)
@bergmeister Current decision by PS-Committee is to not make any change in Windows PowerShell so to not introduce a regression. The issue with PowerShellGet can be solved by PowerShellGet team.
Thanks @bergmeister and @SteveL-MSFT. I'd be happy with any solution that isn't repeatedly having to educate users about -SkipPublisherCheck -Force
. Who is best to approach about making an exception within PowerShellGet for Pester?
Thanks again, Chrissy
@potatoqualitee please open an issue here: https://github.com/powershell/powershellget, I think if the publisher is trusted even if the publishing cert changed, PowerShellGet shouldn't stop the install (perhaps a Warning is ok).
Can we do anything about this, or should I close this issue?
We can revisit it at a later time - if/when PowerShellGet updates their processes. But if they chose to say "Don't care about the Publisher, but do care if it's still signed", it'd be great if Pester was signed (it'd be great either way).
Thanks for the quick response and feedback, everyone!
this can be reopened considering the update at https://github.com/PowerShell/PowerShellGet/issues/233
@nohwnd if you can code sign pester that will fix the issue here and in PowerShellGet
Version 4.4.3 is the first signed version, now I just need to keep them signed in the future as well.
Seems that even with this release that Pester is complaining about the signed certificate this way:
S C:\Windows\system32> Install-Module -Name Pester -Force -RequiredVersion 4.4.3 PackageManagement\Install-Package : A Microsoft-signed module named 'Pester' with version '3.4.0' that was previously installed conflicts with the new module 'Pester' from publisher 'CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US' with version '4.4.3'. Installing the new module may result in system instability. If you still want to install or update, use -SkipPublisherCheck parameter. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21
Hmm, yes, but this is just PowerShellGet being a jerk as usual if you run Install-Module PowerShellGet -Force
to update to a newer version of it, then it should be better
cc @webguynj (not sure if you would get the notification otherwise)
you might actually need both -SkipPublisherCheck
and -Force
due to the way that the Publisher Check works
Or if you have Admin on your machine (or can get an admin to do this) then deleting the Pester 3.4.0 version completely from your system will get rid of that error completely ( though might need to take control from Trusted Installer account to do so IIRC)
Since 1.6.3
version of PowerShellGet There is exclusion for Pester and PSReadline (described in the referenced issue), so the -SkipPublisherCheck
should not be needed. Unless you install Pester version that is not signed (before 4.4.3
) or you are using PowerShellGet that does not have the exclusion (before 1.6.3
). In both cases I can only recommed updating.
To remove the previous built-in version of Pester from your system you do have take ownership and reset permissions, here is a script that automates the whole process. Then you will have no warnings as @kilasuit said.
1. Provide a general summary of the issue in the Title above
First, Pester is awesome and people are loving it. We created a framework around Pester with dbchecks and the reception has been very positive.
I saw #900 and know it's a known limitation but have a proposed solution below.
3. Expected Behavior
Pester is catalog signed
4.Current Behavior
Pester is not catalog signed
5. Possible Solution
DigiCert offers free Code Signing Certs for MVPs.
6. Context
We include Pester as a required module in dbachecks and have to explicitly say everywhere how to first update Pester the manual way.
Install-Module Pester -SkipCatalogCheck -Force
Even though we state this everywhere, we still get questions.
Also, we signed our module but realized it's not as useful if all required modules are not signed. I can get our other module, PSFramework, signed but won't pursue that avenue without Pester being signed.