Open LanceMcCarthy opened 4 years ago
@LanceMcCarthy thank you for report. I think wrapping inline scripts to temporary ps1 files is something that actions/runner does. cc: @ericsciple @dakale could you please take a look if it is something that should be transfered to your repo?
Thanks @maxim-lobanov
@ericsciple @dakale
I did try to run run: Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -Force
before the other steps. However, that command also gets wrapped as a ps1, lol.
For the above command, a different shell should work:
steps:
- shell: cmd
run: dotnet restore some.csproj
We can't sign user scripts with a GitHub certificate.
transferring to runner repo
I'm already signing other things during the workflow, is there a way I can sign the autogenerated ps1 file before it gets sent to the self-hosted runner?
@LanceMcCarthy did the command with a different shell work for you?
@LanceMcCarthy did the command with a different shell work for you?
I think it worked, but honestly don't remember because I switched back to the GitHub-hosted runners that don't have this issue. I'll have to try it again and see if it still an issue.
@ericsciple FYI using CMD instead of Powershell is not a solution because 90% of the scripts do not work in CMD. There are dependencies on PS modules.
GitHub must maintain the level of trust as those items are executed, the simple solution is to fix the runner or sign the generated PS1
@zzjrzz In case you're curious, here's the repo that I'm doing all of this in https://github.com/LanceMcCarthy/MediaFileManager
Assuming a default install of the runner on Windows,
psexec -i -u "nt authority\network service" powershell.exe
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser
Ideally the service should run with a virtual account instead of network service.
I'd like to upvote as well.
This is really frustrating. Turning off security on the system as a whole is not a great work around.
Then again, blindly signing any scripts that come from user supplied workflows could be problematical.
Maybe there should be an organization or repo specific singing cert or flag to prevent this. Organizations could then at least control the execution of their own scripts?
Secondly, maybe I'm doing it wrong but I did try setting the execution policy and despite running as a user with full administrator rights and doing "Run as Administrator" it fails:
The net result is that Runners are broken for windows.
Could there be an execution_policy
setting to automatically run Set-ExecutionPolicy -Scope Process $policy
workflow-, job-, or step-wise in the workflow YAML files?
The runner could simply run pwsh.exe -ExecutionPolicy $policy $temp_script
.
Assuming a default install of the runner on Windows,
- download psexec
- execute
psexec -i -u "nt authority\network service" powershell.exe
- in the Powershell prompt, run
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser
Ideally the service should run with a virtual account instead of network service.
There is no need for additional tools to Set-ExecutionPolicy. psexec is considered as a hacking tool and might cause head ache for security operation center. Security best practices expect that GitHub signs their static executables including DLL-s they release.
...
steps:
- name: powershell allow...
shell: cmd
run: powershell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser"
- name: check powershell version
run: $host.Version
...
Description
GitHub/Microsoft does not sign autogenerated ps1 scripted steps, this causes a failure on a self-hosted Windows runners.
For example, let's take this step:
Run dotnet restore some.csproj
Which is turned into the following ps1 file that gets downloaded to the runner:
C:\actions-runner\_work\_temp\7af2df60-c729-42fb-85a1-d9de2fd74369.ps1
However, when the runner tries to execute it, you get the expected trust error:
The file C:\actions-runner\_work\_temp\7af2df60-c729-42fb-85a1-d9de2fd74369.ps1 is not digitally signed. You cannot run this script on the current system.
The workaround is to change execution policy, but this is extremely dangerous and a very bad idea. Microsoft should sign any ps1 steps it creates.
Area for Triage:
Question, Bug, or Feature?:
Bug
Virtual environments affected
Expected behavior
Steps work
Actual behavior
Steps fail due to unsigned ps1 file.
Repro steps
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
For a repro example, you can use the following: