microsoft / microsoft/winget-pkgs

[New Feature]: Waiver for publisher endpoints that block the validation service (403/406)

Open
#408,472 1 comment 2 reactions 0 assignees View on GitHub
Area-Validation-Pipeline Issue-Feature
Dominant language
No language data
Stars
11.1k
Forks
9.7k
PR merge metrics
PR metrics pending

Description

### Description of the new feature/enhancement

Some publishers actively block the winget-pkgs validation service while serving the same URLs perfectly well to normal browsers. The site returns `403 Forbidden` (or `406`) to our validator, producing a `URL-Validation-Error` even though every URL in the manifest is correct and publicly reachable. A recent example is McAfee (`https://www.mcafee.com/...`) in [PR #401175](https://github.com/microsoft/winget-pkgs/pull/401175), where the pipeline reported `Http status code: Forbidden` for `mcafee.com` URLs that resolve fine in a browser.

Today a contributor hitting this has only two options, both bad:

1. Leave the correct URLs in place and stay permanently blocked on `URL-Validation-Error`; or
2. Remove or obfuscate the URLs (and even the publisher name) to force validation green.

In PR #401175 this pressure led a contributor to comment out all publisher URLs **and** replace letters in "McAfee" with Cyrillic homoglyphs so the brand/URL checks would stop firing. That is exactly the kind of metadata corruption our policies exist to prevent, and it was driven by the absence of a sanctioned escape hatch.

The [Validation Failure Guide](https://github.com/microsoft/winget-pkgs/blob/master/doc/ValidationFailureGuide.md#url--domain-errors) says that when a URL works locally but not in validation the contributor should "add a comment and an engineer will investigate," but there is no durable, low-touch mechanism to actually record and apply that decision. It does not scale and it is not discoverable.

**Goal:** provide a moderator-gated waiver so a known-good publisher endpoint that forbids our validator can be accepted with the real URLs kept in the manifest - never by removing or obfuscating them.

### Proposed technical implementation details (optional)

A moderator-applied waiver label plus a matching policy-bot handler:

- **New label:** `Validation-Endpoint-Blocked` (name TBD). Asserts "a listed URL is a known-good publisher endpoint that forbids our validator; skip the reachability/HTTP check for it." Applied **only** by moderators / super-moderators / engineers, never by contributors.
- **New policy handler** (`.github/policies/labelAdded.validationEndpointBlocked.yml`), modeled on `labelAdded.urlValidationError.yml`: on label add, post a short templated note explaining the waiver and why, clear the blocking `URL-Validation-Error` state, and allow the PR to proceed once it otherwise passes. End the reply with `Template: msftbot/waiver/endpointBlocked`.
- **Guardrails - reachability only.** The waiver must NOT bypass SmartScreen reputation, `Validation-Domain` / `Validation-Unapproved-URL` (wrong-publisher-domain), or any `Policy-Test-*` content review. The domain must still be the publisher's own, and the URLs must remain in the manifest (removal is not rewarded).
- **Optional curated allow-list** of domains known to block the validator (e.g., `mcafee.com`) so recurring cases can be waived automatically with an audit trail, rather than a one-off label each time.
- **Docs:** add a `Validation-Endpoint-Blocked` row to `ValidationFailureGuide.md` and a short note in `Policies.md`, reinforcing "keep the URL and request the waiver," never "remove or obfuscate."

**Open questions for the team:**
1. Final label name.
2. Who may apply it - moderators only, or engineers only?
3. Per-PR label vs. curated domain allow-list vs. both.
4. Should a waiver expire or require re-review on the next version bump?

**Why a label rather than a pipeline change:** the policy-bot path is reversible, auditable, moderator-scoped, and ships without touching the validation pipeline. If the pattern proves common, the reachability validator itself could later treat a curated allow-list as a soft-pass.

_(Created with GitHub Copilot assistance.)_

Contributor guide

Open the contributing guide

Research direction

Start by reading .github/policies/labelAdded.urlValidationError.yml, ValidationFailureGuide.md, and Policies.md to understand the existing policy-bot flow and documentation conventions. Resolve the open questions about label scope and waiver coverage with maintainers before proceeding. Done means a moderator-gated endpoint-blocked waiver is documented and its reachability-only behavior is auditable without bypassing other validation policies.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, markdown, yaml
Domain
ci-cd, documentation, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.