-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Disable local manifest by default #1453
Conversation
@ImJoakim Hey, I just wanted to let you know this change is coming. The PowerShell scripts will likely need to be modified for testing local manifest files once this change is released. We had a security review, and the decision was made to make this disabled by default. Most users will not need to execute local manifest files. This requires administrative access to modify, so it's not in the local settings file. |
Seems fair since there is just about max 10 active contributors that might have to test a package locally..
What if there is a way to temporary allow local manifests instead of toggling it once to use it one time? |
That's an interesting approach. Are you thinking about having the command just work for the "next" execution rather than an "on/off" switch? |
For now, the toggle setting stays until it's changed explicitly by user later. If users want to test local manifests, they'll run 'winget settings --enable LocalManifestFiles', after the testing is done, they could use 'winget settings --disable LocalManifestFiles' to disable it. If there's need in the future, we can add an option to make the toggle be effective only once. |
I have PowerShell's execution policy on my mind, however since winget is a appx package there is a lot less to worry about, we do need a on/off switch, however i believe it would be nice for people to have a next or temporary switch, i was thinking of |
Given the current code structure, I think I can easily add an option 'winget settings --enable LocalManifestFiles --once', which will allow next local manifest invocation(could be either non elevated or elevated), then the feature is disabled after invocation. Does that sort of satisfy the "temporarily enable" ask? Thanks. |
Two questions:
|
Doesn't this defeat the purpose of a security risk? If can answer, what is the security concerns you guys are thinking about? |
Yes, there's an existing one named LocalManifestFiles.
The 'winget settings --enable LocalManifestFiles --once' still needs to be invoked as elevated. The next run with local manifest input could be non elevated. Regarding questions about what security concerns, I think mainly we don't want to be the entrypoint to install random apps potentially without user knowledge, but I guess I'll let @denelon elaborate. |
Shoot, that's what I get for not checking the admx file again. I remember that being there now, thanks! |
That can't work; it would require admin to set the "consumed" state or it would be possible to just set it back to unconsumed. While we don't run with any more permissions than a potential attacker, we don't want to make it any easier to download and run some binary either. Given that 99% of users will never run |
Alrighty, that makes sense. Just going to have to be another consideration when running local manifest tests. Thanks for looping me in @denelon. |
Edit: Correct, it won't work. I forgot the secure setting part. Anyway, as you said, given the rare use cases for this feature, I'm totally fine with an on/off switch only. |
for (const auto& warning : User().GetWarnings()) | ||
context << Workflow::EnsureRunningAsAdmin; | ||
|
||
if (!context.IsTerminated()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole point of the workflow is to never check this; you just make a task that does what you need to do (the block inside the if) and invoke it. #Resolved
|
||
if (!valueNode || !valueNode.IsScalar()) | ||
{ | ||
AICLI_LOG(Core, Info, << "Admin setting '" << name << "' was not found or did not contain the expected format"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AICLI_LOG(Core, Info, << "Admin setting '" << name << "' was not found or did not contain the expected format"); | |
AICLI_LOG(Core, Verbose, << "Admin setting '" << name << "' was not found or did not contain the expected format"); | |
``` #Resolved |
auto stream = Settings::GetSettingStream(Settings::Streams::AdminSettings); | ||
if (!stream) | ||
{ | ||
AICLI_LOG(Core, Info, << "Admin settings was not found"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AICLI_LOG(Core, Info, << "Admin settings was not found"); | |
AICLI_LOG(Core, Verbose, << "Admin settings was not found"); | |
``` #Resolved |
AdminSettingsInternal adminSettingsInternal; | ||
bool isEnabled = adminSettingsInternal.GetAdminSettingBoolValue(setting); | ||
|
||
// For some admin settings, even if it's disabled, if the corresponding policy is enabled then override it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would put this above the code that just read in the settings stream and return directly so that we don't waste cycles doing that. #Resolved
Change
Due to security concerns, this change disables local manifest files by default. User can still turn on local manifest files through group policy, or through running 'winget settings --enable LocalManifestFiles' as administrator.
Validation
Added tests. Also tested manually.
Microsoft Reviewers: Open in CodeFlow