fix(scripts): derive consent-preview fields from the signed manifest - #2
Merged
Merged
Conversation
entry-from-release regenerated a builtin's registry entry but wrote only version + package, leaving permissions / optionalPermissions / hostPermissions and engines as hand-authored leftovers that silently drifted from the plugin's actual manifest. Incident: motrix.filename-template@1.1.0 dropped hostPermissions from its manifest, yet the entry kept advertising a broad wildcard host grant. The website and app showed a healthy update that then failed to install client-side — the registry lied to users about what the plugin requests. buildPackageBlock now mirrors engines + the three permission arrays off the already-verified SIGNED manifest and carries them in the returned block; patchEntry writes them unconditionally so a stale value can never survive. Absent optional manifest fields (hostPermissions / optionalPermissions) land as [], which the registry wire schema's .default([]) accepts and materializes identically for consumers. A missing engines.motrix is treated as a corrupt manifest and aborts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
entry-from-releaseregenerated a builtin's registry entry but wrote onlyversion+package, leavingpermissions/optionalPermissions/hostPermissions/enginesas hand-authored leftovers that silently drift from the plugin's actual signed manifest.Incident:
motrix.filename-template@1.1.0droppedhostPermissionsfrom its manifest, yet the live entry still advertises["*://*/*"]— the consent preview shown on the website and in-app no longer matches what the plugin requests, and the offered update fails to install client-side.How
buildPackageBlocknow mirrorsengines+ the three permission arrays off the already-signature-verified manifest (newManifestMirror), andpatchEntrywrites them unconditionally alongsideversion+package— no code path lets a stale value survive. Absent optional manifest fields land as[](identical to the wire schema's.default([])materialization). A missingengines.motrixaborts as a corrupt manifest. Editorial fields (name/description/categories/features/…) remain hand-authored.Test plan
hostPermissionsclears the stale wildcard and stays schema-valid):pnpm test→ 27 passedpnpm checkclean,pnpm validate→ 3 entries valid