Would this improve validation?

[denelon]

Our current validation environment tests packages run as "admin".

We've seen a number of packages where validation fails as a result.

I'm going to try and use this discussion as a poll. Please don't add comments unless you have an alternate suggestion to what is proposed so we don't have to scroll through "Me too", or "No way" comments. We're going to look at 👍 and 👎 on the questions.

[denelon]

Should we run as "admin" for manifests with "Machine" scope?

Remember, we're going to look at 👍 and 👎 on the questions.

[denelon]

Should we run as "user" for manifests with "User Scope"?

Remember, we're going to look at 👍 and 👎 on the questions.

[denelon]

If no scope is specified in the manifest should we continue to run as "admin"?

Remember, we're going to look at 👍 and 👎 on the questions.

[RokeJulianLockhart]

Maybe one prompt for which type of authority it should executed as shall be superior. That way, exploitation of this shall not be possible because manual escalation shall be required.

This obviously shall not be ideal for automation, but if this is configurable, it shall be what I am believing is ideal.

[denelon]

Do you have a different or better suggestion?

Do you think this is going to create a large number of failures?

Comments on this reply are fine 😊

[dorssel]

At least for MSI installers, software can actually support both (either machine-wide, or current-user only). If software really supports only one type, the manifest should indicate so. And "not specified" should imply: can be either. As an example: vscode.

If winget is being used by a standard (non-admin) user, I would say that "per-user" as a default is best (and avoid UAC, etc.). Admins can always use --scope to opt-in for system-wide.

Maybe the bot should try both scopes if none is specified in the manifest. And if either one fails: give an error about missing "scope" in the manifest.

[dpprdan]

Inno installers also support both (#18505 (comment)). On an upgrade, it may automatically use the scope set before.

[sredna]

NSIS (Nullsoft) supports all 3 (User, Highest and Admin). WinGet does not really handle the UAC Highest manifest request but I suppose it could in theory. To handle Highest WinGet would have to explicitly tell Windows not to elevate if the user prefers the user scope.

[lychichem]

Not only test both and watch the return code, the bot should also test whether there is changes to ARP list or install location to confirm the package really installed. Here I want to mention the fucking tencent.tencentmeeting package again. It will always return "success" in any mode, but you can only really install it as admin.

[jedieaston]

Related to that, I proposed a strict mode for winget install that would verify the correct ARP changes were made: microsoft/winget-cli#1478

I don't know if anyone else wants it, but for determining if anything actually happened it would be very useful.