Skip to content
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

Manually replace unqualified cmd, powershell paths for the default profiles #12149

Merged
3 commits merged into from
Jan 12, 2022

Conversation

zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Jan 12, 2022

In previous releases, we had the commandlines for the Command Prompt and PowerShell profiles unqualified, as cmd.exe and powershell.exe. This was bad - theoretically, that would have preferred the cmd that was in the CWD over the one in System32. Or, something could insert itself into the path, and you'd end up with a malicious cmd.exe before the real one.

In #11437, we made sure that the userDefaults are initiated with the fully qualified paths. However, that didn't fix the issue for folks who already had settings files.

In an effort to better prevent this kind of badness, if we see a profile with a default profile guid, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one.

@ghost ghost added Area-Settings Issues related to settings and customizability, for console or terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. labels Jan 12, 2022
@miniksa
Copy link
Member

miniksa commented Jan 12, 2022

if we see a profile with a default profile guid, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one

Got instantly translated in my head to "IF YOU SEE SOMETHING, SAY SOMETHING®"

if (profile.Guid() == DEFAULT_COMMAND_PROMPT_GUID &&
profile.Commandline() == L"cmd.exe")
{
profile.Commandline(L"%SystemRoot%\\System32\\cmd.exe");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we call ClearCommandline instead, to reset it to the inherited value? this would be somewhat more ergonomic in the settings UI and somewhat less ergonomic in the JSON, but it won't require us to repeat ourselves in three places with the new commandlines

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three months later . . .

Resetting to the inherited value will be bad when it was inherited from a different profile. Like... profiles.defaults.

Incidentally, this will always be a little weird because we have no way of knowing the user actually didn't set these themselves.

We could check the profile GUIDs (ew)

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noted

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jan 12, 2022
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jan 12, 2022
@DHowett
Copy link
Member

DHowett commented Jan 12, 2022

@msftbot merge this in 18 minutes

@ghost ghost added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jan 12, 2022
@ghost
Copy link

ghost commented Jan 12, 2022

Hello @DHowett!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

  • I won't merge this pull request until after the UTC date Wed, 12 Jan 2022 21:49:07 GMT, which is in 18 minutes

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

@ghost ghost merged commit f1baa31 into main Jan 12, 2022
@ghost ghost deleted the dev/migrie/b/12126-correct-old-cmdexe-paths branch January 12, 2022 21:50
@DHowett DHowett added the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Jan 21, 2022
DHowett pushed a commit that referenced this pull request Jan 21, 2022
…ofiles (#12149)

In previous releases, we had the commandlines for the Command Prompt and PowerShell profiles unqualified, as `cmd.exe` and `powershell.exe`. This was bad - theoretically, that would have preferred the cmd that was in the CWD over the one in System32. Or, something could insert itself into the path, and you'd end up with a malicious `cmd.exe` before the real one.

In #11437, we made sure that the `userDefaults` are initiated with the fully qualified paths. However, that didn't fix the issue for folks who already had settings files.

In an effort to better prevent this kind of badness, if we see a profile _with a default profile guid_, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one.

* Related to #11437
* [x] fixes #12126
* [x] Tests added

(cherry picked from commit f1baa31)
@DHowett DHowett removed the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Jan 26, 2022
@ghost
Copy link

ghost commented Feb 3, 2022

🎉Windows Terminal Preview v1.13.10336.0 has been released which incorporates this pull request.:tada:

Handy links:

ghost pushed a commit that referenced this pull request Apr 18, 2022
#12149 introduced a bug where `ClearCommandline()` is called on any user
profile containing the non-canonical strings "cmd.exe" or "powershell.exe"
in the "commandline" field. If you happen to have set the "commandline"
field in your `profiles.defaults`, this will cause these user profiles
to adopt the base layer command-line instead of the defaults layer one.

This commit fixes the issue, by checking the command-line after the call
to `ClearCommandline()` and ensuring it's the expected string.

Additionally this moves the migration logic to `SettingsLoader` as this allows
us to write the fixed settings to disk, if any fixed had to be applied.

## PR Checklist
* [x] Closes #12842
* [x] I work here
* [x] Tests added/passed

## Validation Steps Performed
* The modified unit test fails without these changes ✅
* The modified unit test succeeds with these changes ✅
* Setting `profiles.defaults.commandline` to "pwsh.exe" and setting
  my "...\\powershell.exe" profile to use just "powershell.exe" as
  the `commandline`, doesn't cause it to use "pwsh.exe" ✅
  The fixed settings are written to settings.json ✅
DHowett pushed a commit that referenced this pull request Apr 21, 2022
#12149 introduced a bug where `ClearCommandline()` is called on any user
profile containing the non-canonical strings "cmd.exe" or "powershell.exe"
in the "commandline" field. If you happen to have set the "commandline"
field in your `profiles.defaults`, this will cause these user profiles
to adopt the base layer command-line instead of the defaults layer one.

This commit fixes the issue, by checking the command-line after the call
to `ClearCommandline()` and ensuring it's the expected string.

Additionally this moves the migration logic to `SettingsLoader` as this allows
us to write the fixed settings to disk, if any fixed had to be applied.

## PR Checklist
* [x] Closes #12842
* [x] I work here
* [x] Tests added/passed

## Validation Steps Performed
* The modified unit test fails without these changes ✅
* The modified unit test succeeds with these changes ✅
* Setting `profiles.defaults.commandline` to "pwsh.exe" and setting
  my "...\\powershell.exe" profile to use just "powershell.exe" as
  the `commandline`, doesn't cause it to use "pwsh.exe" ✅
  The fixed settings are written to settings.json ✅

(cherry picked from commit 0138a6f)
Service-Card-Id: 80690111
Service-Version: 1.13
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When default profile is set to Command Prompt, "Open in Windows Terminal" uses cmd.exe in current folder
3 participants