unable to detect PowerShell due to group policy blocking registry access

[begoldsm]

Description

In the previous version of GitHub desktop client I could specify PowerShell as the shell to launch for a given project, and it gave me cool information in the command line about the current state of the repo (if I was ahead/behind, conflicts, changes, etc.). There is no longer an option for me to select PowerShell in the new version. There is a drop down in advanced options for shell, but it only has "Command prompt" in it.

Version

GitHub Desktop version: 1.0.4

OS version: Microsoft Windows [Version 10.0.15063]

Steps to Reproduce

1. Launch the client
2. Go to File -> Options and click on the Advanced tab
3. Click the drop down for Shell.

Expected: A number of shells are available (cmd, ps, bash, etc.)
Actual: only cmd is available.

4. Launch the cmd shell for a project.
   Expected: it gives data about the local branch vs. tracking branch in the command line
   Actual: it does not.

Expected behavior: That I can use PowerShell for git through github desktop client and that it gives me information in the shell about the branch.

Actual behavior: It is not possible and I can only use a command prompt with no info.

Reproduces how often: 100%

Logs

Additional Information

[shiftkey]

@begoldsm thanks for the details.

This is how we detect if you have a version of PowerShell installed:

desktop/app/src/lib/shells/win32.ts

Lines 41 to 53 in a6fcd1a

	const powerShell = await readRegistryKeySafe(
	'HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\App Paths\\PowerShell.exe'
	)
	if (powerShell.length > 0) {
	const path = powerShell[0].value.replace(
	/^%SystemRoot%/i,
	process.env.SystemRoot || 'C:\\Windows'
	)
	shells.push({
	shell: Shell.PowerShell,
	path,
	})
	}

Is that registry key missing on your machine? Do you know of a better way to check that PowerShell is installed?

it gives data about the local branch vs. tracking branch in the command line

This is posh-git which isn't bundled by default in Desktop Electron, but the install options should help you get it setup.

[begoldsm]

Oh great, thank you for these details @shiftkey! Looking at my HKLM path there is no registry entry there at all for "App Paths" on this machine (I am running on a current generation SurfacePro, if that makes a difference). I will keep digging and let you know what I find (or if there is some way I can get that path hooked up). Thanks again!

[begoldsm]

A place that I found that it is always present is in the system PATH environment variable ($env:Path or %PATH%). Not sure if you can get access to that easily though. One other thing, it looks like group policy on this machine does not allow user accounts to read into certain registry locations, which explains why you can't find it (looking at that path as the local admin I can see that the App Path entry exists and has powershell.exe in it).

It looks like I spoke too soon, my user can get the full list of app paths in a current user window, so the current user can see the PowerShell.exe path:

> get-item "HKLM://SOFTWARE/Microsoft/Windows/CurrentVersion/App Paths/PowerShell.exe"
    
    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths


Name                           Property
----                           --------
PowerShell.exe                 (default) : C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe

[shiftkey]

@begoldsm does that mean this issue is sorted?

[begoldsm]

Not quite, since for some reason the UI still does not see that powershell is installed. Is there some log that I can look at to see what kind of "failure" it gets when attempting to read that registry location?

[shiftkey]

@begoldsm not really, all the magic is in that snippet I linked to above.

EDIT: actually, there's some debug messages that will appear in the dev tools around how we interact with the registry - View | Toggle Developer Tools menu item, then switch to the Console tab and set the filter to Verbose - maybe there's something in there after reproducing the steps

[begoldsm]

@shiftkey awesome! I will give that a shot right now and report back with my findings. Thank you!

[begoldsm]

The verbose output isn't giving me any information as I navigate through the UI. I am searching for the two potential errors that I see in the readRegistryKeySafe() funciton and no errors are happening when I click the drop down for the shell in advanced, nor is this error showing up on initial load:

desktop/app/src/lib/registry.ts

Line 111 in a6fcd1a

`Unable to find batch script at expected location: '${batchFilePath}'`

[shiftkey]

@begoldsm ensure you are opening the File | Options menu item to trigger the registry interactions

[begoldsm]

@shiftkey I think I have figured it out. It appears that the logic used to read the registry is being blocked by group policy since it attempts to open the registry location in rw mode. When I launch GitHub desktop as an admin, it is properly finding PowerShell, but when it is launched as a standard user (without admin privileges), it cannot read that key (even though the key is readable through other means as a regular user).
At this point, I would say the "fix" is to either use a different, more restrictive system friendly way of determining if PowerShell is available or to come up with a way to install the client in a way that requires admin access only during setup and then maintains its own copy of config settings (maybe?)

[shiftkey]

I think I have figured it out. It appears that the logic used to read the registry is being blocked by group policy since it attempts to open the registry location in rw mode. When I launch GitHub desktop as an admin, it is properly finding PowerShell, but when it is launched as a standard user (without admin privileges), it cannot read that key (even though the key is readable through other means as a regular user).

That's interesting, because we're reading the registry using reg.exe with the QUERY command:

desktop/app/static/win32/registry.bat

Lines 8 to 14 in fd971fb

	if %ACTUAL_ARGS_COUNT% EQU %EXPECTED_ARGS_COUNT% (
	chcp 65001
	CALL %WINDIR%\System32\reg.exe QUERY %1
	chcp %2
	)

I'm not sure if there's a simpler way to do this that won't trigger this group policy, but I'm open to suggestions for alternatives.

[shiftkey]

@begoldsm

I think I have figured it out. It appears that the logic used to read the registry is being blocked by group policy since it attempts to open the registry location in rw mode.

I'd like to inflict this group policy on myself and see this behaviour first hand. Is it this Group Policy rule that's enabled for you?

[danilaml]

This SO answer might provide a solution.

[begoldsm]

@shiftkey yes, that is the policy that is set for all our domain accounts. @danilaml that is potentially a solution, but I wonder if there is some other way to read from the registry without attempting to open it in edit mode (rw). The registry is still accessible (I can use powershell to Get-Item HKLM://...), it just can't be opened for writes.

[iAmWillShepherd]

Fixed in #3209

[shiftkey]

This hasn't been fixed yet - #3209 was superseded by #3492.

[iAmWillShepherd]

Ah, my bad 😭

[arshmohd]

@shiftkey yes, that is the policy that is set for all our domain accounts. @danilaml that is potentially a solution, but I wonder if there is some other way to read from the registry without attempting to open it in edit mode (rw). The registry is still accessible (I can use powershell to Get-Item HKLM://...), it just can't be opened for writes.

Were you able to get around this, I am running into the requirement, registry read is blocked due to GP, is there another way around to just read the registry?