microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).

https://learn.microsoft.com/windows/package-manager/

MIT License

23.27k stars 1.45k forks source link

Define Download Directory #1208

Open michha opened 3 years ago

michha commented 3 years ago

Brief description of your issue

our company has AppLocker enabled with an allow-list of directories that executables can be started
when installing a package (like Git.Git) it results in the following error (manually translated into english)

Installer-Hash successfully validated Package installation is going to start... Unexpected error during execution of command: 0x8007029c : An assert error has occured.
the applocker event log states

The execution from %OSDRIVE%\USERS\SOMEUSER\APPDATA\LOCAL\PACKAGES\MICROSOFT.DESKTOPAPPINSTALLER_8WEKYB3D8BBW E\TEMPSTATE\WINGET\GIT.GIT.2.32.0.EXE was blocked.

Expected behavior

We should be able to set the package directory where the packages are downloaded and executed. A option within winget settings should be added to override the default location.

Actual behavior

With AppLocker enabled, we can not use winget, because executables cannot be run inside the users profile path.

Environment

Windows Package Manager v1.0.11451
Windows: Windows.Desktop v10.0.19042.1052
Paket: Microsoft.DesktopAppInstaller v1.11.11451.0

denelon commented 3 years ago

We have a change coming in the next release to change the download location to %TEMP% https://github.com/microsoft/winget-cli/pull/1146.

denelon commented 3 years ago

This looks like it might be the same thing as #970.

michha commented 3 years ago

We have a change coming in the next release to change the download location to %TEMP% https://github.com/microsoft/winget-cli/pull/1146.

This would not help us as the temp directory is the main directory for malicious scripts and programs and therefore also blocked by AppLocker.

Like I said, everyone with AppLocker needs a configuration option for the path from which the exe, msi and so on will be started.

denelon commented 3 years ago

Based on your comment, this does look like a duplicate of #970.

denelon commented 3 years ago

Duplicate of #970

ghost commented 3 years ago

@michha we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.

paalders commented 3 years ago

@denelon I stubled across this issue as well. In my opinion this is not the same as #970. This issue is about the temp folder that is used by winget to download and run the installer. #970 is about the target directory of the software to be installed into. Both of these locations are blocked by AppLocker software, since all of them base in %LOCALAPPDATA%. The applications are installed in \Programs\ and the installer is run from \Temp.

As a target install directory I can image people might want to install into the C:\Program Files\ folder, or something else. This location a user will not want to use for the temporary data stored by winget during installation, which this issue is about. I can image that you'd might to set this folder to C:\Temp\ or something different.

denelon commented 3 years ago

@paalders I'll discuss this with the team. If there aren't any major blocking reasons associated with a user specified location, I'll re-open the Issue and mark the appropriate comments "No longer applicable". If not, I'll share the reasons so we can look for alternative solutions. One of the benefits we might lose is the ability to use the "Disk Cleanup" behavior associated with "Temporary Files".

denelon commented 3 years ago

We still have some concerns regarding long path names, but it looks like this is a different ask than what I initially understood.

michha commented 2 years ago

@denelon Whats the status about this issue. We are still struggling with winget because we cannot set the temporary folder for the package content.

denelon commented 2 years ago

We will be tackling standalone .exe and .zip packages in 1.3. I'm highly expecting we will be looking at how we handle paths for those types of packages. It will likely make sense to bring this in with that effort. We will also need to include the information via winget --info as logs from some installers tend to get placed in the directory the installer runs from.

denelon commented 2 years ago

@michha this didn't make the cut for 1.3, and .zip will be moved to 1.4 as well. I'll put this into the 1.4 milestone to see if the team can fit this in.

bpe71 commented 1 year ago

This didn't make it in v1.4?

denelon commented 1 year ago

Sadly, no. We did get .zip support included in 1.4, but there wasn't enough time to look at supporting alternate paths for where we download and run installers from.

michha commented 1 year ago

In the latest 1.5 preview I couldnt find any reference to this issue. Will there be a fix for this issue in 1.5?

We really need an environment variable to give winget a hint for the temporary folder it should use.

denelon commented 1 year ago

@michha take a look at the Roadmap to see how we generally prioritize work. This Issue simply doesn't have enough "demand" yet to move up very high in the backlog. I've moved it into the v.next milestone rather than the backlog to see if there is more interest or need for this work.

Trenly commented 1 year ago

[Policy] Area-Settings