Skip to content

PS extension sets execution policy? #2404

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rjmholt opened this issue Jan 6, 2020 · 5 comments · Fixed by PowerShell/PowerShellEditorServices#1208
Closed

PS extension sets execution policy? #2404

rjmholt opened this issue Jan 6, 2020 · 5 comments · Fixed by PowerShell/PowerShellEditorServices#1208
Labels
Milestone

Comments

@rjmholt
Copy link
Contributor

rjmholt commented Jan 6, 2020

I've been hitting an issue where I couldn't debug scripts because, even though my execution policy was set machine-wide to Bypass, my integrated console was reporting RemoteSigned.

It looks like this is set here but I'm not sure why. Shouldn't we just inherit the right execution policy?

@SydneyhSmith SydneyhSmith added the Needs: Triage Maintainer attention needed! label Jan 7, 2020
@TylerLeonhardt
Copy link
Member

We already start with Bypass so I don't really see why we need this. We should get rid of that code.

@SydneyhSmith SydneyhSmith added Area-Debugging Issue-Bug A bug to squash. Area-Startup and removed Area-Debugging Needs: Triage Maintainer attention needed! labels Jan 9, 2020
@IainM-NZ
Copy link

The integrated terminal should follow the machine settings, it's frustrating having to set the policy each time. New (powershell) terminals created do use the correct execution settings, no reason for the integrated one to be different.

@ghost ghost added the Needs: Maintainer Attention Maintainer attention needed! label Feb 21, 2020
@rjmholt
Copy link
Contributor Author

rjmholt commented Feb 21, 2020

Ok I've played with this a bit now. It's not trivial.

When we start PSES, we're forced to run it with execution policy Bypass to be able to load the modules that users depend on as part of their experience. That means we can't simply inherit the execution policy, since it's been overridden.

So the remaining solution is to remember the initial execution policy and transmit that. The problem there is that the starting process is node, rather than PowerShell, meaning we'd need to start another PowerShell process to discover the execution policy, leading to greater startup time cost.

Increasing startup time is something I'm fairly reluctant to do, since it's already a pain point. But I'm not sure what other avenues are available to us to fix this.

@SeeminglyScience
Copy link
Collaborator

So the remaining solution is to remember the initial execution policy and transmit that. The problem there is that the starting process is node, rather than PowerShell, meaning we'd need to start another PowerShell process to discover the execution policy, leading to greater startup time cost.

You can query the other scopes in the same process, so running something like below before we run profiles could work.

$userPolicy = Get-ExecutionPolicy -Scope User
if ($userPolicy -ne [Microsoft.PowerShell.ExecutionPolicy]::Undefined) {
    Set-ExecutionPolicy -Scope Process -ExecutionPolicy $userPolicy -Force
    return
}

$machinePolicy = Get-ExecutionPolicy -Scope Machine
Set-ExecutionPolicy -Scope Process -ExecutionPolicy $machinePolicy -Force

Does really make me wish setting it to Undefined wasn't a no-op though...

Anyway, still not free, but cheaper than starting another process.

@rjmholt
Copy link
Contributor Author

rjmholt commented Feb 21, 2020

I was just having a similar thought! I’ll keep plugging on this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants