Document security best practices for in-app self-updates - #489
Open
RDMacLachlan wants to merge 2 commits into
Open
Document security best practices for in-app self-updates#489RDMacLachlan wants to merge 2 commits into
RDMacLachlan wants to merge 2 commits into
Conversation
Add a "Security best practices for self-updating apps" section to the non-Store in-app update guidance, covering capability minimization (don't declare packageManagement/packageQuery unless managing other publishers' packages), the same-publisher enforcement that acts as a safety net, protecting a persisted update source, and why manually pre-verifying an incoming package generally isn't necessary. Resolves AB#31658694 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Learn Build status updates of commit 83848bc: ✅ Validation status: passed
For more details, please refer to the build report. |
- Replace emdashes with commas to match the file's punctuation. - Convert italic emphasis to bold to match the file's existing emphasis convention (e.g., the bolded 'not' used elsewhere in the document). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 18e32334-aec6-40fd-a4f8-0631ef4d5840
Contributor
|
Learn Build status updates of commit b1fa165: ✅ Validation status: passed
For more details, please refer to the build report. |
DrusTheAxe
reviewed
Aug 2, 2026
|
|
||
| ### Declare only the capabilities you need | ||
|
|
||
| Don't declare the `packageManagement` or `packageQuery` [restricted capabilities](/windows/uwp/packaging/app-capability-declarations#restricted-capabilities) unless your app needs to install, update, or query packages that are published by a **different** publisher. An app can update and uninstall packages published by the **same publisher** (for example, another app from your own company) without declaring `packageManagement`. Interactive installs through [PackageManager.RequestAddPackageAsync](/uwp/api/windows.management.deployment.packagemanager.requestaddpackageasync) also prompt the user for consent and don't require the capability. |
There was a problem hiding this comment.
packageManagement and packageQuery capabilities are only relevant if you run in an AppContainer
If not then it's mot. The docs here read like they're written back in days of yore when (only) UWP apps roamed the land...
Fix
DrusTheAxe
reviewed
Aug 2, 2026
|
|
||
| If you persist the location of your update (for example, a URL that you store so it can be fetched later) treat that value as untrusted input. [Application data](/windows/apps/develop/data/store-and-retrieve-app-data) is writable by the full-trust user, so another process running as that user could modify a stored update URL. Validate the stored value before you use it, and prefer well-known, hard-coded, or server-verified sources over values that can be freely rewritten on the client. | ||
|
|
||
| ### Do you need to inspect the incoming package first? |
There was a problem hiding this comment.
"same-publisher enforcement" - you sure that's a thing? See comment in other PR
|
|
||
| ### Do you need to inspect the incoming package first? | ||
|
|
||
| You generally don't need to open and inspect an incoming package to verify its identity before you install it. Rely on the platform's same-publisher enforcement (described above) rather than manually pre-vetting package identity. When your app hasn't declared `packageManagement`, the platform already prevents you from silently installing another publisher's package, so manually validating the package first adds complexity without meaningfully strengthening that guarantee. |
There was a problem hiding this comment.
That would severely degrade perf (implies you're downloading the package to peek inside it before handing it to Deployment)
If you do need to ensure appropos source, use Package Validation
There was a problem hiding this comment.
P.S. Where's the https://learn.microsoft.com page about Package Validation? :P
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
2 participants
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.
Summary
Adds a Security best practices for self-updating apps section to
msix-src/non-store-developer-updates.md, documenting the in-app update security story raised in this bug.The guidance covers:
packageManagement/packageQuery; omitting them lets the platform enforce same-publisher-only operations as a safety net.The new section is appended at the end of the file to avoid overlapping with PR #482 (AB#25739271), which edits the intro/capability portion of the same document.
Resolves AB#31658694