Strict Microsoft package signature validation

[awakecoding]

Description of the new feature/enhancement

winget currently makes no distinction between packages provided by Microsoft and community packages, such that there is no way to install Microsoft software that is not shipped in-box like Windows Admin Center or PowerShell 7 with a guarantee that everything downloaded and executed was exclusively signed by Microsoft. The idea would be to make enforcement of signature validation tied to a specific vendor like Microsoft when installing packages: when installing WAC or PowerShell 7, one would have the same kind of guarantee of origin one would expect from Windows Update. A Microsoft package not signed by Microsoft would fail to install.

Proposed technical implementation details

The vendor signature enforcement could be controlled by command-line options, but my recommendation would be to enable it by default for official Microsoft packages, with the Microsoft key pair or certificate trusted by default. This is very similar to how Linux package repositories work (https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7.1#ubuntu-1804).

As for the signature mechanism, the most important part is to sign the manifest file. Yes, the manifest contains CDN URLs and the hash of the files, but it's not of much use if the manifest is unsigned because it could be tampered with. A relatively simple way to implement this today would be to borrow the same kind of signature down with OCI artifacts and containers using cosign from the sigstore project: https://github.com/sigstore/cosign

This issue is related to #702 because it intends to meet the recurring demand for including out-of-box Microsoft software like WAC and PowerShell 7 in-box. I believe that if we provide a fully trusted way to install additional out-of-box Microsoft software without relying on community packages, this demand would be met. If winget can enforce proper trust of origin on Microsoft software, then it's not that much different from calling Install-WindowsFeature. It would be a trustworthy option, rather than simply a convenient option.

[jedieaston]

I think the current idea is that microsoft/winget-pkgs#100 will solve this. ISVs (or, in this case, Microsoft) will restrict packages in the community repo so that they are the only ones that can merge changes to them.

It's not as strong as signatures (hypothetically someone could screw with GitHub and merge changes bypassing the policies), but we could generally trust that the manifests were correct. Does that not work for you?

[awakecoding]

I think the current idea is that microsoft/winget-pkgs#100 will solve this. ISVs (or, in this case, Microsoft) will restrict packages in the community repo so that they are the only ones that can merge changes to them.

It's not as strong as signatures (hypothetically someone could screw with GitHub and merge changes bypassing the policies), but we could generally trust that the manifests were correct. Does that not work for you?

This would not be sufficient, I really mean it when I say the manifests should be cryptographically signed by the vendor. What you are suggesting is having a way to let vendors control ownership over the manifests published in the community repository. The main difference is that if someone were to take control of the winget-pkgs repository and merge a malicious manifest, the cryptographic signature would not be valid. In order to push a malicious manifest with a valid signature, one would need to steal the keys used for the signatures (Microsoft in this case).

In theory one could very well mix the Microsoft packages with the community packages inside one same repository, but then the problem is that it becomes difficult to tell automatically which package must be signed by which vendor (and key pair). The simplest option is to break down packages into vendor-specific repositories and automatically enforce signature validation for all packages inside that repository with the vendor key pair.

Relying on package signatures also has one big advantage: it makes it possible to cache the entire set of manifests + download corresponding files for offline installation. Since the manifests are signed and refer to immutable artifacts by their hash, it doesn't matter where you download them from - you can still validate the signatures anyway. Offline installation with trust of origin from Microsoft would be excellent for Windows Server, where not all installations are done with internet access.

[awakecoding]

@SteveLasker @sajayantony this would be another interesting application of signed manifests

[doctordns]

This approach would solve a lot of issues using winget (and winget cmdlets) in the server arena.