chocolatey / chocolatey/choco

Should we continue to allow "insecure root" installation?

Open
#3,531 0 comments 0 reactions 0 assignees View on GitHub
0 - Triaging Enhancement
Dominant language
C#
Stars
11.5k
Forks
960
PR merge metrics
No merged PRs in 30d

Description

### Checklist

- [X] I have verified this is the correct repository for opening this issue.
- [X] I have verified no other issues exist related to my request.

### Is Your Feature Request Related To A Problem? Please describe.

During work on #3501 it was noted that there still exists an `$env:ChocolateyAllowInsecureRootDirectory` environment variable that is part of the installation logic.

If it is not set, you _cannot_ use `$env:ChocolateyInstall` to set the installation location to `C:\Chocolatey`. If it is set, the installer allows it.

### Describe The Solution. Why is it needed?

Given we are removing the migration behaviour and we do not support this installation scenario, we should look at removing this undocumented behaviour that permits it in the first place as well.

Additionally, currently it only checks for `C:\Chocolatey` as the "insecure root directory" however, so there are some questions as to what we _should_ allow here.

- Do we just remove the check and always allow whatever is set in `$env:ChocolateyInstall`? (probably a bad idea given we saw fit to prevent installing to `C:\Chocolatey` _specifically_ in the past?)
- Do we expand the check to not allow installing to a folder that is on the root of the system drive _in general_?
- Do we _just_ disallow installing to `C:\Chocolatey` specifically -- if so, why?

Additionally, when we remove the undocumented environment variable, we should likely add a warning if folks try to use it for at least a version or so, so those using it are aware it now is not functional.

### Additional Context

_No response_

### Related Issues

_No response_

Contributor guide

Open the contributing guide

Research direction

Trace the installation logic that reads $env:ChocolateyAllowInsecureRootDirectory and review the context from issue #3501. Decide which installation paths should be allowed and how deprecation should be communicated. Done means the policy is documented in the implementation and the obsolete variable receives the agreed warning or removal treatment.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, powershell
Domain
cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.