PSGetModuleInfo.xml invalidates the module .cat file

[f0rt]

Team,

After publishing and installing a module from PS Gallery we get one additional file called PSGetModuleInfo.xml. After calling Test-FileCatalog I get "ValidationFailed" result. This way our customers cannot verify the module content.

Thanks, f012rt

[iSazonov]

@f0rt Thanks for your report. Please add a version information.

[anmenaga]

Easy workaround is to use -FilesToSkip PSGetModuleInfo.xml parameter; for example:

PS C:\> Test-FileCatalog "C:\Program Files\WindowsPowerShell\Modules\Microsoft.PowerShell.Archive\1.1.0.0\Microsoft.PowerShell.Archive.cat"
ValidationFailed
PS C:\> Test-FileCatalog "C:\Program Files\WindowsPowerShell\Modules\Microsoft.PowerShell.Archive\1.1.0.0\Microsoft.PowerShell.Archive.cat" -FilesToSkip PSGetModuleInfo.xml
Valid

[f0rt]

Here is the version information:

Name Value

---

PSVersion 5.1.15063.674 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.15063.674 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1

Is this going to be fixed? Because if not we should notify our customers.

[iSazonov]

@f0rt Can you use workaround with -FilesToSkip? I suppose this parameter just addresses your scenario.

[f0rt]

We can. The problem is that we're getting reports from customer about this issue. If this is not going to be fixed I guess our PMs will address with a blog post.

[joeyaiello]

@anmenaga can we talk about this at some point? Got some more context, not sure how we should fix it.

[ghost]

Install-module is creating this file. It's where we store certain metadata, notably what repository (think PowerShellGallery) the item came from. We're investigating what we can do. For now, I am planning a blog topic explaining the issue & workaround.

[ThomasNieto]

@SydneyhSmith / @alerickson any way we could get this fixed with PSGet 3.0?

[SydneyhSmith]

@ThomasNieto thanks for bringing this up, we are happy to explore if this fits into PowerShellGet 3.0....do you have any suggestions as to what you would like to see in PowerShellGet to fix this....one option would be to use the Save-PSResource cmdlet without the parameter -IncludeXML (which is currently available in 3.0), another way for users to check would be a -PublisherCheck parameter on Install (which has not yet been implemented)

[ThomasNieto]

@SydneyhSmith My recommendation would be to move all non-module shipped files out of the module directory so Test-FileCatalog will succeeded by default without any workarounds.

To accomplish that the PSGetModuleInfo.xml would be moved into a separate directory like how installed script information is stored in a InstalledScriptInfos directory. The same could be done for modules storing the XML files in ~\Documents\PowerShell\Modules\InstalledModuleInfos or $env:ProgramFiles\PowerShell\Modules\InstalledModuleInfos.

This would be a breaking change since v2 wouldn't be able to find the file anymore but currently Get-InstalledModule doesn't return modules installed with v3.

The only additional check I can see is when reading the xml files is to check to see if the module directory still exists as there is a possibility that the user could have manually deleted the module. Right now this is handled automatically since the xml file resides in the same directory as the module.

[alerickson]

@ThomasNieto that's a pretty simple solution! We can definitely do that. As you mentioned, it's not necessary that v3 modules work with v2 cmdlets, so I don't see any issue with creating a directory to store the file in.

Can we move this issue to PowerShellGet?

[ThomasNieto]

@alerickson I found that Get-Module returns a PSModuleInfo with a ResourceRepositoryLocation property. You'll want to update this logic to flex the old or new file path.

https://github.com/PowerShell/PowerShell/blob/8f37cced709168f313a00b2e3ee7088495bbcd7a/src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs#L2596-L2619

[4c74356b41]

I just came across this behaviour. I'm not sure is it me being thick, or its not possible to install signed modules from PSGallery? Here's how I publish the module:

New-Item `
    -Force `
    -Type Directory `
    -Path "C:\Program Files\WindowsPowerShell\Modules\nimbus\$moduleVersion"

Get-ChildItem `
    -Exclude "*json","runbook*" `
    -Recurse `
    -Path "module\path\*" `
    -File | Foreach-Object {
        Set-AuthenticodeSignature `
            -TimestampServer "http://timestamp.digicert.com" `
            -Certificate $cert `
            -FilePath $_.FullName | Out-Null
    }

New-FileCatalog `
    -CatalogFilePath "module\path\nimbus.cat" `
    -CatalogVersion 1.0 `
    -Path "module\path\"

Set-AuthenticodeSignature `
    -TimestampServer "http://timestamp.digicert.com" `
    -Certificate $cert `
    -FilePath "module\path\nimbus.cat" | Out-Null

Copy-Item `
    -Destination "C:\Program Files\WindowsPowerShell\Modules\nimbus\$moduleVersion" `
    -Exclude artifacts `
    -Recurse `
    -Force `
    -Path "module\path\*"

Publish-Module `
    -RequiredVersion $moduleVersion `
    -NuGetApiKey $NuGetApiKey `
    -Name nimbus

When I publish, there is no PSGetModuleInfo.xml file in the module. This is confirmed by the post on this thread. So when I do Install-Module nimbus it fails, because of the cat file check that is automated and the check fails due to the PSGetModuleInfo.xml, which gets injected into a module?

[4c74356b41]

@ThomasNieto hey mate, can you shed some light on this? is it currently not possible to sign modules and upload to psgallery?

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.68. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[4c74356b41]

@SydneyhSmith so tagging this with 3.0 resolved means this won't ever be fixed in 2.0 and we should not sign the modules?

[TravisEz13]

You can Authenticode sign individual files (where applicable, including psd1, psm1, ps1xml, and dlls), or NuGet sign the package. PowerShellGet does not currently verify NuGet signing but that is how the package should be signed.

To enable verification a signature in PowerShell, you need to switch on AllSigned policy or use Windows Code Integrity.

@4c74356b1 Can you message me on twitter so I can understand your exact requirement?

[TravisEz13]

I created a script to verify the publisher signing and give detailed results to find what @4c74356b41's issue was.

https://gist.github.com/TravisEz13/70263b0bd6b1e747dac2d116245f419e

It gives this result for the module, which looks like this

[kilasuit]

@4c74356b41 - You can 100% publish and install signed modules - what the issue is here is that the 'PSGetModuleInfo.xml' should be hidden on the filesystem, which it definitely is on windows

@ThomasNieto thanks for bringing this up, we are happy to explore if this fits into PowerShellGet 3.0....do you have any suggestions as to what you would like to see in PowerShellGet to fix this....one option would be to use the Save-PSResource cmdlet without the parameter -IncludeXML (which is currently available in 3.0), another way for users to check would be a -PublisherCheck parameter on Install (which has not yet been implemented)

@SydneyhSmith - re the above it would make sense to move to a single file for User installs & a single file for System wide installs as opposed to individual files dotted around in each installed module version folder? This would also make Get-InstalledModule quicker too

[4c74356b41]

@TravisEz13 thats true, thats for figuring that out. funny enough, it started working after I removed those 2 files from the cat file. but the cat file still doesn't pass the check :)

[ThomasNieto]

@SydneyhSmith can we get this bug fix / enhancement worked on before v3 GA so there is no breaking change? The fix @kilasuit recommended https://github.com/PowerShell/PSResourceGet/issues/286#issuecomment-719848944 I feel is the best solution for this problem with added benefits to making discovery faster.

[SydneyhSmith]

@ThomasNieto happy to take another pass through this issue and see what we can do