Should we continue to allow "insecure root" installation?
- 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
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