Unattended Update

[TobiasPSP]

When a user has installed modules from an untrusted repository such as the PowerShell Gallery, running Update-Module will raise a confirmation dialog again. Effectively, this prevents users from being able to unattendedly update their existing (and already approved) modules.

The only way to deal with the confirmation currently is:

• Change the trust level and make PowerShell Gallery trusted: since this would affect installation of new modules as well, it would introduce security issues.
• Use the parameter -Force: since this would also reinstall any up-to-date module, this would introduce new issues and network traffic

Would it be possible to add a parameter to just skip confirmation? There should be a way for users to update their modules unattendedly and make sure they are always up-to-date.

Or is there any other recommended best practice how to keep installed modules up-to-date without manual interaction?

[Sarafian]

Not sure I understand the functional difference between -Force and e.g. -SkipConfirmation in this context. Since the usage of -Force is not persisted, aren't you doing exactly the same with skipping confirmation?

[TobiasPSP]

-Force skipts confirmation and also reinstalls all modules (if I understand correctly). This is taken from the help: "If the module is already installed, Force reinstalls the module."

So when you do a full update using -Force, you would see no confirmations (yay!) but you would also re-install all modules that are up-to-date. There is no reason why we would want to reinstall modules that are perfectly fine. We are looking for a way to frequently and automated check for updates, so most likely in most scenarios all updates would be up-to-date, and in this scenario -Force would reinstall them all each time.

In fact, since -Force has always been part of this cmdlet, adding a parameter .e.g. -SkipConfirm would essentially be just a "milder" form of -Force and shouldn't introduce any new security concerns. After all, a user would still actively confirm that it is ok to install, albeit not interactively but by using the new parameter.

[Sarafian]

Indeed, the -Force parameters has two roles

1. Re-Install a module when there is no reason to "update"
2. When there is a reason the "update" accept the untrusted repository. This is also where different warning show up

I would argue that the problem is with mixing scopes and I'm not sure if new parameter would make things simpler or not. Because you are not sure on which scope of -Force you are acting on. In my opinion, confirming to install from an untrusted repository should not be bypassed because we trust the publisher. But then, the -Force is already mixing things.

[jhoneill]

When I tested this, it seems that Windows PowerShell 5 skips if the version in the repo is already installed and PowerShell 7 re-installs even without -force It seems to me the desire here is to say

1. This repo is still not trusted. I have validated one module from and will consider updates to that module to be trusted, but I don't want to trust anything else in the repo.
2. If the version installed is the current one in the repo (trusted or untrusted), don't re-install the same version.

This is possible but needs work Get-Module -listavailable gives all versions - we can discover the latest installed version, then find if there is a newer version, and if so we can install that.

Get-module -ListAvailable  | Group-object -property 'name' | Foreach-object {
    $version = ($_.group | measure-object -maximum -property version).maximum
    find-module $_.name | where-object  -property version -gt $version
}  | update-module -force

To @Sarafian's comment.
By established custom -Force does two things

1. "Don't stop when the operation can be carried out , even if the circumstances would normally cause it to be skipped with a warning or error" - for example overwriting something
2. "Act as -Confirm:$false" because specifying $false for a switch is not considered to be discoverable. My own code uses a common pattern that allows user to specify both -confirm and -force (you can't put common parameters into parameter sets to prevent this) and -force will take precedence - the logic goes if ($force -or -$pscmdlet.shouldProcess()) so when force is specified the shouldProcess() is not evaluated.

I think in this case -Confirm:$false should prevent the prompt, but not force an overwrite - although see my opening comment that I seem to be getting overwrites on V7.

[SydneyhSmith]

This is a very interesting scenario...some solutions we have discussed, that would be great to get feedback on, especially since we are trying to decouple the confusing force behaviors of v2:

• A parameter available on Update (and potentially on install) that is something like -SkipTrustCheck in order to avoid the check at an individual update call (we currently are not using the -Force parameter, and have introduced a -ReInstall parameter, so we could also call this -Force)
• Ability tot configure repositories trust at the update vs install level, for example always trust updates, never trust installs
• One related solution we have discussed is the ability to configure trust at the publisher or namespace level, in addition to the repository level, for example you may not want to trust the PowerShell Gallery as a whole but you may want to trust all modules (verifiably) published by Azure PowerShell

[Sarafian]

I believe that the original reason behind the default lack of trust, even for the gallery is the scripting nature of powershell, same as with the requirement for signed scripts execution . With the maturity of PowerShell I think it is a realy a good idea to implement the 3rd bullert

One related solution we have discussed is the ability to configure trust at the publisher or namespace level, in addition to the repository level, for example you may not want to trust the PowerShell Gallery as a whole but you may want to trust all modules (verifiably) published by Azure PowerShell

With that in mind, you don't have to differentiate between install and update of a module because you implicitly trust version of the module.

[ThomasNieto]

You can use the -TrustRepository parameter to suppress the untrusted repository prompt now.