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
Write PowerShell Activate.ps1 to be static so it can be signed #81535
Comments
If Activate.ps1 was made to not have substitutions upon generation and be an entirely static file, then the file could be signed and thus not require people to lower their security requirements in PowerShell in order to activate their virtual environments. |
How would you plan to replace the functionality where the venv's bin path is substituted into the script? Purely through introspecting its own path? I see that PowerShell is/will be portable to e.g. Linux environments, but I presume the security requirements you refer to are purely a Windows constraint - is that right? |
It's stored in pyvenv.cfg.
Yes (at least for now; not sure what PowerShell Core plans to do about this sort of thing long-term). |
How will this interact with EnvBuilder.install_scripts() (which explicitly states that it performs textual substitution)? Note that I'm not aware of anyone who actually uses the ability to subclass EnvBuilder, but I wouldn't be surprised to find that people do... |
Is it? $ python3.8maint -m venv --prompt "foo bar" /tmp/venv
$ more /tmp/venv/pyvenv.cfg
home = /home/vinay/projects/python/3.8
include-system-site-packages = false
version = 3.8.0
prompt = 'foo bar' The source Python location is stored, but not, from what I can see, the venv path itself ... though of course that can be worked out from $PSScriptRoot or similar.
If there's nothing to substitute (because the script source has no placeholders), that won't constitute a problem, AFAIK. |
One thing to note is that if we sign this file, it'll have to bypass the text substitution step completely to avoid modifying line endings or encoding. So there could be code changes in venv too. This would be a great contribution from a PowerShell expert, and might be worth advertising (Twitter) for one. File parsing can get tricky quickly, but there are a few clever ways to approach it. We also need to set a minimum PowerShell version to support, as plenty of its features aren't available on base Windows 7 installs. |
It won't, so that would have to change as well. As you mentioned, Paul, I don't know who even uses the functionality through a subclass, but since this is a security consideration I think it's worth changing.
Sorry, misread what you were asking. You're right it's not stored, but it can be worked out in other ways, e.g. from the location of pyvenv.cfg or Activate.ps1, etc.
Yep, hence making the issue now so that others talking about adding more substitution ideas know that there's talk going the other way and removing the substitution abilities.
Already have a co-worker interested in working on it. |
I just chatted with Derek about this, and while we identified some potential regressions (previously we were injecting str(prompt) into Activate.ps1, and now we're showing repr(prompt)), I don't think they're widely used. For example, if you previously did:
You'd get 'my\nprompt' in pyvenv.cfg, but an actual newline in your printed prompt (note that passing "my\nprompt" in the command doesn't do this). There are likely other things that will be escaped in the configuration that previously would have been fine with the direct substitution. I have no real sense of how widely used these are. They are definitely less popular than machines that are configured to require code-signed Powershell scripts, so we still come out ahead. It's probably easy to handle some of the more common escapes, if we know what they are, but I doubt we're going to reimplement full Python string parsing in a Powershell script. Vinay - any thoughts here? For me, I think get it out in 3.8.0b4 and see how it fares. |
Thanks, Derek! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: