Cannot install Scoop due to AllSigned Powershell execution policy

[nicerloop]

Bug Report

Current Behavior

I cannot use nor reinstall scoop on my work computer since the machine and user execution policies of AllSigned have been enforced by a group policy, and I cannot override and lower it to RemoteSigned as expected by scoop.

Expected Behavior

I can install and use scoop even with an executionpolicy of AllSigned.

Additional context/output

Possible Solution

It seems signing the scripts is required to execute the script with AllSigned execution policy. It seems it has been attempted already, but abandonned in favor of using RemoteSigned execution policy (#330)

System details

Windows version: Windows 10 Enterprise 21H1

OS architecture: x64

PowerShell version: 5.1.19041.1682

Additional software:

Scoop Configuration

{
    "lastupdate":  "2021-12-23T16:29:52.0175045+01:00",
    "SCOOP_REPO":  "https://github.com/lukesampson/scoop",
    "SCOOP_BRANCH":  "master",
    "alias":  {

              }
}

[rashil2000]

There's no solution to this: I have the same problem on my work computer and my workaround is to install PowerShell 7. The new PowerShell's execution policies are independent of system PowerShell and can be edited by you.

[nicerloop]

I just tried with PowerShell 7.2.4 from zip distribution, and I still cannot use scoop as the domain global policies of AllSigned are also applied by powershell 7.

This means that I will have to remove sccop from my work machine and find another package manager, possibly chocolatey.

[chawyehsu]

I think this is a management issue not technical issue. A proper way to solve this is to talk to your IT admin.

[rasa]

IT may not want to provide exceptions. Do we need to code sign something? I found Comodo at USD $55/year. Is there anything cheaper? I would consider contributing this, if it would get around this issue.

[rashil2000]

Chocolatey is also installed through a PowerShell script, so you're going to face the same problem there

[rasa]

Certum offers Open Source code signing certs for $25 Euros/year. Will this work? It's unclear why the effort was abandoned in #330 (comment) in 2015.

[chawyehsu]

IT may not want to provide exceptions. Do we need to code sign something? I found Comodo at USD $55/year. Is there anything cheaper? I would consider contributing this, if it would get around this issue.

Requires that all scripts and configuration files be signed

Not against it but maybe you'll need to sign all scripts including those behind the installer (core, per bucket/manifest script) to make it work under the Allsigned policy according to the doc. If this is the way, it will be horrible for Scoop development and updates, because every time new commits get merged to core the codebase/signature change and will needs to re-sign to work.

P.S. It's not really a bug...

[rasa]

This restrictive security setting must be very rare, or we would have lots of users complaining, right?

[sarog]

Opinion: The maintainers of Scoop need to sign their scripts.

Rationale: The maintainers of Scoop are missing the point of digitally signing their scripts.

The roles of code signing and permitting script execution are two separate responsibilities:

1. Code Signing guarantees that the scripts are from the maintainers of Scoop and that they are not tampered with while in transit.

2. An application or script that is digitally signed allows the System Administrator to whitelist CA & CS certificates in the Trusted Publishers store, thus allowing script execution to occur on end-user workstations with the most restrictive security settings. This includes not only AllSigned, but implementations of AppLocker, SRP and/or WDAC along with blocking outbound connections from executables such as powershell.exe, pwsh.exe and others.

Note: The Certificate Authority does not necessarily have to be from a trusted CA; a "Scoop CA" with separate Code Sign certificates can be distributed for every trusted developer. To be clear: there is no need to purchase a certificate from a third-party. A YubiKey can be used to manage certificate private keys.

Now, let's clear up some FUD.

This restrictive security setting must be very rare, or we would have lots of users complaining, right?

Home users won't complain since it's very easy to ignore the warnings and blindly bypass PowerShell execution policies. However, managed environments that DO use Scoop for package management will benefit tremendously. Also, did you consider power users who prefer to have an extra peace of mind knowing that the scripts haven't been tampered with?

I think this is a management issue not technical issue. A proper way to solve this is to talk to your IT admin.

"Management" can't do anything when the scripts are not signed. I'd love to add Scoop to a whitelist in my environment, but it's not possible without having something to reference the scripts by. And no, no sane sysadmin will whitelist an entire folder of scripts.

Not against it but maybe you'll need to sign all scripts including those behind the installer (core, per bucket/manifest script) to make it work under the Allsigned policy according to the doc. If this is the way, it will be horrible for Scoop development and updates, because every time new commits get merged to core the codebase/signature change and will needs to re-sign to work.

Automatic code signing and timestamping can be added in any IDE and/or CI/CD pipeline. It took me a whole minute to sign all the Scoop scripts using the following PowerShell:

$cert = @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0]
$files = "~\scoop\shims\scoop.ps1", "~\scoop\shims\scoop.ps1", "~\scoop\apps\scoop\current\bin\scoop.ps1", "~\scoop\apps\scoop\current\libexec\*.ps1", "~\scoop\apps\scoop\current\lib\*.ps1"
Set-AuthenticodeSignature -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.digicert.com' -FilePath $files -Certificate $cert

I realize the shims are created on demand and can't be signed by the maintainers.

P.S. It's not really a bug...

Yeah, it's either ignorance or negligence at this point. :/

[rashil2000]

Hi @sarog, thanks for the detailed write-up! I'll admit I'm not that well-versed in code-signing - so it was quite informative.

Would you consider making a PR for this, or for setting up the infra for automatic code signing?