[New Feature]: Add security related metadata on manifest files.

Open
#156,818 3 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Domain
security, tooling

Research direction

Start by reviewing the existing manifest files and how manifest metadata is consumed in this repository. The issue proposes update-type metadata, per-package overrides, and additional package information, but names no files or tests. Done would require an agreed scope and schema before implementation can be identified.

Written by the indexing model from the issue text.

Description

Area-Manifest Issue-Feature
Description of the new feature/enhancement

Looking at the existing manifest files, I begin to realize that you are missing the most important feature I want in a package manager:
The distinction between different update types (security fix, functionality fix, feature update).
I want the package manager to be able to auto-update only the packages that have security fixes (although, someone else might want to also include functionality fixes).
If it can adjust its behavior on a per-package basis too, in the form of an override, it might be even better.

Proposed technical implementation details (optional)

Allow a field in the manifest file that specifies the update type (e.g., critical risk security fix, medium risk security fix, low risk security fix, functionality fix, feature update). This will be set by the author.
Also, you can (and should) probably allow a combination of update types per package version (e.g. security fix and feature update at the same time).
When exploits for a piece of software comes out, you could auto-update the existing manifest files (and the field mentioned above) for all versions of the software, without the author having to do anything. I believe that all exploit databases out there do specify which versions are affected by an exploit, so this should be easy. And the package manager could retrieve, display, and act upon this information.

P.S. :
You could also include more metadata, like the type of software (GUI app, command-line app, SDK, driver, firmware, codec, font, etc).
Also, the target OS name, just to be flexible. E.g. "above Windows 7", "above Win10", "Windows Nano (which we all hope gets resurrected...)", Linux, etc.
Also, software/hardware dependencies, like DirectX9, MSVS C++, TPM 2, etc.
Amount of required RAM/disk, etc.

Dominant language
No language data
Stars
11.1k
Forks
9.7k
Avg merge
1h 32m
Merged PRs (30d)
376

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/winget-pkgs

All issues in microsoft/winget-pkgs

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.