Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict access to manifests for packages #100

Closed
denelon opened this issue May 12, 2020 · 9 comments
Closed

Restrict access to manifests for packages #100

denelon opened this issue May 12, 2020 · 9 comments
Assignees
Labels
Area-Validation-Pipeline Issues related to the manifest validation pipeline. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Milestone

Comments

@denelon
Copy link
Contributor

denelon commented May 12, 2020

Some software vendors will want to manage releases for manifests of their software.

@denelon denelon added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label May 12, 2020
@denelon denelon changed the title Restrict access to manifests for commercially owned packages Restrict access to manifests for packages Jun 2, 2020
@denelon
Copy link
Contributor Author

denelon commented Jun 2, 2020

Some OSS producers also wish to manage releases for manifests and installers for their software.

@denelon denelon added this to the Packages Backlog milestone Jun 3, 2020
@denelon
Copy link
Contributor Author

denelon commented Jan 6, 2021

@denelon denelon added the Area-Validation-Pipeline Issues related to the manifest validation pipeline. label Jan 6, 2021
@ghost ghost added the No-Recent-Activity No activity has occurred on this work item for seven days. label Jan 13, 2021
@ghost

This comment has been minimized.

@ocdtrekkie
Copy link

Why was WinGet 1.0 released/announced without completing this incredibly security-critical goal?

@denelon
Copy link
Contributor Author

denelon commented Sep 16, 2021

The technical implementation for this feature is complete. We are now working on the business process for identifying verified developers. The implementation is similar to the waivers for validation stored in a .version file. The ownership metadata will be recorded in a .package file.

@denelon denelon closed this as completed Sep 16, 2021
seejdev pushed a commit to seejdev/winget-pkgs that referenced this issue Nov 4, 2021
## Change
Due to issues we are seeing with deploying directly from the URL, this change moves the client to download the msix file first, and deploy it from a local file.  This is intended to be a temporary measure until we can investigate the direct deployment issue further, but it may need to become permanent depending on the result of the investigation.

## Testing
Manually validated that the change works against the production environment with source add and automatic update.
@slonopotamus
Copy link
Contributor

The technical implementation for this feature is complete.

After re-reading this whole issue six times, I still fail to understand how this feature was implemented and how to use it. Could you please give a link to some docs or whatever?

@denelon
Copy link
Contributor Author

denelon commented Mar 21, 2022

We are still working on the business process for this feature. Once that has been completed, the technical implementation here will be further documented.

The simple overview of the technical implementation is we will have a file in the directory (either publisher, or package) identifying the verified developers GitHub alias. When a PR is submitted by anyone other than the verified developer, they will be informed. If the verified developer submits a PR, the validation will continue down the normal process.

@ocdtrekkie
Copy link

I'm still deeply concerned this thing is actually on real Windows PCs that actual people use prior to this being implemented.

@russellbanks
Copy link
Contributor

Just a thought, what about scenarios like LF/CRLF line ending enforcement? We would need to ensure that the pull request pipeline fails if line endings are incorrect first, as we wouldn't be able to normalise the manifest at a later stage if we are restricted in changing the manifest for the package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Validation-Pipeline Issues related to the manifest validation pipeline. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Projects
No open projects
Pipelines-v.Next
In progress
Development

No branches or pull requests

7 participants