[New Feature]: Find a better way to handle Nightly packages.

[stephengillie]

Description of the new feature/enhancement

Packages which are actually updated every ~24 hours currently aren't really a good fit for this package manager. Our validation and approval timing means they will at best be available only ~75% of the time, and sometimes will miss for several days.

General timing:

• Developer releases new nightly. (Immediate hash mismatch.) (0 hours)
  • Ideal: the developer has added a PR in our repo to their CI/CD process.
  • Slower: a community member has detected this in some way and created a PR. ("Slower" because there might be a delay between the developer's release and the community member's schedule, introducing additional delay into the process. Add ~1 hour.)
• PR in repo, validation pipelines start. (Hour 0 or 1)
  • Ideal: Pipelines complete (Hour 1 or 2)
  • Slower: Pipelines have either a pipeline error (IEDS) or a package error (other labels). Needs remediation, add ~3 hours. (Hour 4 or 5)
• PR "greenlit" for approval.
  • Ideal: Immediately before an approval run (~7 am or ~5 pm - Hour 1 or 2 / 4 or 5)
  • Slower: Several hours before an approval run. (Add ~3 hours - Hour 4 or 5 / 7 or 8)
• Publish pipeline runs and new version of package becomes available.

The most ideal scenario consumes around 16% to 20% of the Nightly package's lifespan. A slightly impacted but still mostly ideal scenario consumes 33%. Additional delays in this process can easily consume the remaining timespan between releases.

Proposed technical implementation details (optional)

Neither of these ideas is really ideal in the current situation, so please be gentle.

One idea:
The number of manual steps complicates expediting the validation and approval process. There might be some kind of expedited system, where certain developers can become vetted in some way (Authorized Publishers?) and have their nightly packages fast-tracked into the Publish pipeline, while the validation and approval steps are pending. And with the caveat that any failure of those pipelines would cause that nightly version to become reverted. This might present too many legal fronts (not a laywer).

Other idea:
"Known Nightlies" could have a flag, or be on a list, or otherwise enumerated such that they could have reduced restrictions on hash mismatches. The package manager could allow hash mismatch overrides - in conjuntion with the above enumeration. (This might be hidden deep behind large security warnings, where only advanced users (who would opt for a nightly version of a package) would know to enable.) This would allow users with a large risk appetite to continue receiving nightly updates.

[Trenly]

I think your last idea is good, but could be as simple as a new admin setting and GPO in the CLI for allowed hash mismatches. An admin or GPO could set a list of package identifiers that automatically skip the hash validation.

---

Another option may be adding signature checking and a thumbprint to the manifest. That way if a publisher puts out a new version of an application, the CLI could check if the binary is signed and if the signature comes from the correct ISV. An admin setting could be added to the CLI to proceed if the hash does not match but the signature does

---

I know it may be a fair bit of work, but another option could be having a different source in winget specifically for nightlies / vanity URLs.

There could be a separate folder in this repo like manifests_trusted which could have its own publish pipeline that builds it as its own pre-indexed package (source_trusted.msix).

Then, an update to the CLI could add it as a known source which 1) requires admin to enable, 2) can be disabled by GPO, and 3) Automatically proceeds even when hash mismatches occur.

This would allow for very controlled processes (i.e - moderation) to determine whether a package can be sufficiently trusted to be added to the trusted folder. Something like Firefox or Google Chrome would be easily trusted, other applications may have different processes such as needing 15 or 20 nightlies in a row to pass standard validation before becoming a trusted vanity URL.

The manifests in the trusted folder could be updated by the bot just to help ensure that PackageVersion and SHA are kept somewhat up to date. Bot PRs into trusted apps could be auto-merged without moderator approval, as it could be a requirement of becoming a trusted app that the app versioning is something that works with the bot and can be updated. Or, trusted apps could always be listed as "Latest" and have a SHA that is just always wrong but never checked although I think that having them updated occasionally would be best.

---

[DuckDuckStudio]

I also have these issues when submitting packages that update faster:
Before the pull requests for one version of a package are merged, the next version is released.
I'm not sure if I should keep the pull request from the previous version.

And I almost always have Security issues when I submit my programs, and they all work fine after I submit them to Microsoft Security Intelligence. (e.g. #163233 )
This took a lot of time because of the time difference.
Machine translation.

[PckgrTom]

I think this expands slightly further than nightly releases as there are many popular applications currently using vanity URLs. I think it would be great as @Trenly mentioned to have a trusted list for highly reputable vendors like Mozilla and Google that have certain measures in place to reduce updating process. This would help reduce the downtime applications can experience when the vanity URL is broken.

Google Chrome is great example, each week it normally receives and update but sometimes it can be twice a week. If the validation pipeline is running smoothly and it's approved shortly after it can be around 3 hours of downtime for the package. The real issue is when something disrupts the process and it can then become 24 hours of downtime. Not to mention the massive amount of labour involved for @stephengillie who has to approve these packages.