search

microsoft / winget-create

The Windows Package Manager Manifest Creator command-line tool (aka wingetcreate)
MIT License
492 stars 84 forks source link

There should be a way to capture ARP data. #173

Open jedieaston opened 2 years ago

jedieaston commented 2 years ago

Description of the new feature/enhancement

A new command (or options on wingetcreate update) that will have wingetcreate execute the manifest and capture the new Add and Remove Programs table entries, to support the schema changes made in https://github.com/microsoft/winget-cli/issues/1073

Proposed technical implementation details (optional)

Hooray! https://github.com/microsoft/winget-cli/issues/1073 was merged. But how do we get these entries?

I propose that there should be some way (either a new command or some options) added to wingetcreate that will do this for you, by either running a manifest in a separate environment (#98) or running it on the local machine (if it has to run it on the local machine, that's totally fine. We'll just have to run wingetcreate inside a sandbox/VM/container).

The main blocker for this I can think of is whether or not winget itself has some way of exposing what installer entry it matched to (as wingetcreate would have to know what installer entry was installed to get these ARP entries). I know it puts it in the verbose logs, but that isn't fun to parse (maybe it's exposed in the COM API? Haven't looked into that much).

denelon commented 2 years ago

We have been discussing different approaches for "validation" that would include looking at ARP entries and for other possible validation scenarios. This would likely be "behind" an administrator driven setting, but I can certainly see lots of value here. The team has been discussing some of the different approaches we've seen/used like Windows Sandbox and running in a VM. The primary concern is around installing something from a local manifest where we haven't run ~static~ dynamic analysis.

We don't want someone installing a package (assuming the hash passes a local manifest) and thinking they will be protected, when in fact they might have gotten PUA because they installed something that hasn't gone through dynamic analysis.

jedieaston commented 2 years ago

The primary concern is around installing something from a local manifest where we haven't run static analysis.

Aren’t we protected by SmartScreen in this instance? It should pop up if something has failed SmartScreen when winget tries to run the executable (at least, it has for things like Jackett in the past).

The problem I suppose is if SmartScreen hasn’t ever seen the executable before, in which case it wouldn’t know to block it. An interesting solution to this could be to use the Antimalware Scan Interface APIs built into Windows to ask the user’s antimalware software to scan the executable downloaded before winget/wingetcreate proceeds with executing it. If the user’s antimalware software finds something, don’t run it (at which point the user can determine if it’s a false positive, and if so report it to the Defender site or virustotal or wherever). That interface actually seems very nice, especially since it works even if the user doesn’t use Defender.

denelon commented 2 years ago

Sorry, my bad. That should have been "dynamic" analysis.

LeonarddeR commented 2 years ago

As a first step, it would help if we could provide updated ARP entry information on the command line when updating a package, especially if the information is already known without the necessity to install the application.