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

[New Feature]: Throw Validation-Domain when Github URLS don't strongly correlate to the PackageIdentifier #204673

Open
Trenly opened this issue Jan 2, 2025 · 0 comments
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.

Comments

@Trenly
Copy link
Contributor

Trenly commented Jan 2, 2025

Description of the new feature/enhancement

For most packages that are hosted on GitHub, the PackageIdentifier is of the form Organization.RepoName where both the organization and the repo name have been normalized. For example, https://github.com/Example-Desktop/ExampleOne may end up as Example.ExampleOne while https://github.com/Example-Two/Package may end up as ExampleTwo.Package.

In the current state of the pipelines, any GitHub URL seems to pass validation without Validation-Domain, regardless of if they correlate to the package identifier. This means that a fork like https://github.com/denelon/Package could be submitted to the identifier Trenly.Package without ever throwing Validation-Domain. Given the standards already set in the repository, and the need for correct attribution, this should not be allowed.

Proposed technical implementation details (optional)

A new type of domain validation should be applied to GitHub URLs to ensure they point to a heuristically similar fork that the package identifier is claiming. Since it is possible for GitHub organizations to be renamed, or for there to be a genuine need for an identifier to not match the organization, there should be a way to apply a waiver.

It would be best if all GitHub URLs had to have a waiver which correlated the package identifier to a specific repository

@Trenly Trenly added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Jan 2, 2025
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage This work item needs to be triaged by a member of the core team. label Jan 2, 2025
@denelon denelon removed the Needs-Triage This work item needs to be triaged by a member of the core team. label Jan 2, 2025
@denelon denelon added this to WinGet Jan 2, 2025
@denelon denelon moved this to To Do in WinGet Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Projects
Status: To Do
Development

No branches or pull requests

2 participants