Windows Package Manager (winget) provides exciting features to install and upgrade apps on Windows devices. But how does winget actually work and how are new packages integrated? Within this post I want to elaborate on some questions I had when having a closer look into winget.

How does winget find sources?

By default, winget has the following sources configured:

  1. msstore: Microsoft Store (public)
  2. winget: Winget Content Delivery Network (CDN)

When searching for a particular package, e.g: winget search wireshark all configured sources are searched for a match.

lesson learned: winget can install packages from the public Microsoft store and the winget CDN.

How are winget CDN packages provided?

Winget CDN packages reside within a public git repository hosted on GitHub. The repository contains an alphabetic folder structure by vendor and product name holding manifests in YAML format that describe the app details.

The manifests folder within the repo is grouped by the app vendor and app name and YAML contents of a manifest look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

PackageIdentifier: Google.Chrome  
PackageVersion: 108.0.5359.125  
MinimumOSVersion: 10.0.0.0  
InstallerType: wix  
UpgradeBehavior: install  
Protocols:  
- ...  
FileExtensions:  
- ...  
ReleaseDate: 2022-12-13  
Installers:  
- Architecture: x64  
  Scope: user  
  InstallerUrl: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi  
  InstallerSha256: 91411A41F74B03DD135D466A1CB9DC1B9BC58FA6C0EE311EDE5717DAF86863BD  
  ProductCode: '{6EA4A09D-E0E2-358F-B54C-79106D2D2C95}'  
- Architecture: x64  
  Scope: machine  
  InstallerUrl: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi  
  InstallerSha256: 91411A41F74B03DD135D466A1CB9DC1B9BC58FA6C0EE311EDE5717DAF86863BD  
  ProductCode: '{6EA4A09D-E0E2-358F-B54C-79106D2D2C95}'  
ManifestType: installer  
ManifestVersion: 1.2.0

Besides some basic metadata a manifest contains URLs to download the installer for different architectures and installation scopes with a SHA256 hash to verify the integrity.

How are new (versions of) manifests published?

New manifests or changes are submitted to the repositories main branch via GitHub pull request (PR). After approval of the pull request an Azure DevOps pipeline runs that publishes manifests to the winget CDN which seems based on Azure CDN and adheres to a standard winget repository.

Besides some general validation, the pipeline definition also contains external SmartScreen checks against the referenced installers within the manifest to prevent malicious apps being added.

Once the pipeline has completed the package becomes discoverable for the winget client:

That’s how the package submission process looks like from a simplified perspective:

Who adds the manifests?

My initial guess was that the app manifests are provided by the software vendors directly, aren’t they? A closer look into the commit history and breakdown of the #number of commits by commit Author e-mail address domain breaks down to the following results:

… Unfortunately 75% of all commits use a users.noreply.github.com address that hides the real domain for further analysis 🙃. But based on my subjective feelings a lot of packages are submitted by volunteers.

Grouping the commits only by the authors shows that a GitHub user with the username vedantmgoyal2009 authored more than 25% of all packages.

So that’s still a question mark for me who maintains those packages and what’s their motivation to do so… It could also be possible that some people wrote automations to submit new packages automatically once the sources appear.

My 🔑 take-aways

  • Winget supports multiple package sources you can add additional ones or even host your own
  • Winget comes with winget CDN and Microsoft Store as default sources
  • Anyone with a GitHub account can publish or update manifests
  • Manifest submissions ore updates are reviewed via GitHub pull requests
  • Most submissions come from individuals and not necessarily the organisations maintaining the software

Additional resources