Sync onto MsixCore.Packaging when msixcore ships NuGet packages

[aclinick]

Summary

MSIXplainer.Core currently carries its own MSIX parsing foundation. aclinick/msixcore — a C#/.NET 10 port of Microsoft MSIX Core — now implements the same foundation, cross-platform, behind 527 tests and ten adversarial security review rounds. When msixcore ships its NuGet packages, MSIXplainer should consume it and delete the duplicates.

Duplicated today

MSIXplainer.Core	msixcore equivalent
Services/BlockMapParser.cs	MsixCore.Packaging.Integrity.BlockMapParser / BlockMap
Services/ManifestParserService.cs	MsixCore.Packaging.Manifest.AppxManifestParser
Services/BundleManifestParser.cs	MsixCore.Packaging.Manifest.BundleManifestParser
Services/PackageIdentityCalculator.cs	MsixCore.Packaging.PackageIdentity

Two independent implementations of the same format is exactly the situation where one of them quietly rots.

Why msixcore''s version is the one to keep

It was hardened specifically against tamper attacks that MSIXplainer''s readers were never designed to resist:

• Verifies APPX signature binding (AX* indirect-data digests), so a genuine SignTool signature stapled onto tampered content is rejected. The upstream C++ SDK does not do this — src/msix/unpack/AppxSignature.cpp parses AXPC/AXCD and leaves // TODO: unnamed stream for central directory?.
• Bidirectional block-map coverage, fail-closed.
• Snapshot-drift detection so the bytes verified are provably the bytes reported.
• Rejects duplicate / canonically-equivalent part names (another upstream // TODO: ensure that there are no collisions on name!).
• Path-traversal and symlink-escape containment on extract.

Direction of travel

Two MSIXplainer capabilities are moving into msixcore as first-class CLI verbs, because they are package-generic and fully portable (verified: RulesEngine, RuleCatalog, ManifestExplainerService, UpdateDiffService and BandwidthPlannerService contain no Windows API calls — the net10.0-windows TFM is only inherited from the WinUI app):

• msixmgr diff <old> <new> — block-level update delta, comparepackage.exe parity
• msixmgr explain <path> — the ~70-rule manifest rules engine

What stays here: the WinUI app, InstalledPackageService, TerminalLauncher, the bandwidth planner, and the sample manifest.

Note the exit-code contract differs and must be reconciled: msixmgr uses 0 ok / 1 invalid / 2 usage error on every verb, whereas MSIXplainer uses 0 clean / 1 warning / 2 critical. msixcore has settled on keeping 2 = usage error always, with severity gating via an explicit --fail-on <severity> flag. MSIXplainer should adopt the same contract when it switches over.

Blocked on

msixcore publishing MsixCore.Packaging (and optionally MsixCore.Deployment) as NuGet packages. Do not start until then.

Acceptance

• MSIXplainer.Core takes a PackageReference on MsixCore.Packaging
• The four duplicated services above are deleted
• MSIXplainer.Core drops net10.0-windows for everything except InstalledPackageService / TerminalLauncher
• Rules engine + update diff are sourced from msixcore rather than maintained twice
• Exit-code contract aligned with msixmgr
• Existing MSIXplainer.Core.Tests still green