[rbuergi]

Withdrawing my own merged change

#3342 added central PackageVersion pins for the managed SQLitePCLRaw trio.
MeshWeaver.Plugins#1351 landed the real fix concurrently, and it is better on both counts it
differs by. I did not check for a sibling before starting, which is how two people ended up on the
same defect.

1. VersionOverride beside the reason beats a central pin

#1351 puts VersionOverride="3.0.2" on SQLitePCLRaw.core / provider.e_sqlite3 directly in
MeshWeaver.Hosting.Sqlite.csproj, with the argument spelled out there:

nothing in the platform's own src/ consumes SQLitePCLRaw, and a central pin would only take
effect here anyway — while forcing this repository to move its platform pin in the same change to
see it. The version belongs beside the reason.

That is right, and my own PR measured the first half of it: building MeshWeaver.Hosting.Sqlite
against the #3342 tree still resolved 2.1.11, because a bare PackageVersion does not bind a pure
transitive. My change was inert and gated on a pin bump; theirs works immediately.

2. 🚨 My bundle_e_sqlite3 pin was a latent CVE regression

#1351 warns against raising it "to finish the family". The restore graph confirms it:

SQLitePCLRaw.bundle_e_sqlite3 3.0.2
  → SQLitePCLRaw.config.e_sqlite3 3.0.2
  → SourceGear.sqlite3 3.50.4.2          ← NOT SQLitePCLRaw.lib.e_sqlite3

The 3.0 bundle swaps the native engine package, so the lib.e_sqlite3 pin that exists for
GHSA-2m69-gcr7-jv3q stops being the thing supplying the engine. Inert today for the same
pure-transitive reason — which makes it a loaded gun rather than a live break, and exactly the kind
of thing I objected to leaving in place elsewhere today.

Why my probe missed it, which is the part worth keeping: the probe referenced
lib.e_sqlite3 3.53.3 explicitly alongside the bundle, so sqlite_version() answered 3.53.3
and the swap was masked. Its own project.assets.json restored both SourceGear.sqlite3 3.50.4.2 and lib.e_sqlite3 3.53.3 — the evidence was in the file and I read only the runtime
answer. A control held by accident rather than by design turns a green probe into a wrong
conclusion.

What lands here

The three pins go. The comment keeps both findings so the next person reaching for "finish the
family" meets the measurement instead of repeating it:

• the managed trio is deliberately not pinned centrally, and where the fix actually lives;
• never pin bundle_e_sqlite3 to 3.0.x, and why.

MeshWeaver.Graph.Contract — 0 Error(s) 0 Warning(s), Release, -warnaserror.

Refs #3328, MeshWeaver.Plugins#1351

[Copilot]

🟡 Changes recommended

The change removes the CVE-mitigation pin for SQLitePCLRaw.lib.e_sqlite3 while the comment still relies on that pin existing, leaving no enforced patched-engine version.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR backs out the previously added central-package pins for the managed SQLitePCLRaw packages, keeping explanatory context in Directory.Packages.props about why the managed trio should not be centrally pinned and why bundle_e_sqlite3 3.0.x is unsafe.

Changes:

• Removed central PackageVersion pins for SQLitePCLRaw managed packages previously introduced as part of #3342.
• Rewrote the surrounding rationale comment to point at the fix implemented in MeshWeaver.Plugins (Plugins#1351) and to warn against bundle_e_sqlite3 3.0.x.

File summaries

File	Description
Directory.Packages.props	Removes SQLitePCLRaw central pins and updates the inline rationale/warnings around SQLite engine/package selection.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results (shard 1)

475 tests   475 ✅  31s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit c08fee1.

[github-actions]

Test Results (shard 0)

251 tests   251 ✅  2m 22s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit c08fee1.

[github-actions]

Test Results (shard 3)

369 tests   367 ✅  45s ⏱️
  3 suites    2 💤
  3 files      0 ❌

Results for commit c08fee1.

[github-actions]

Test Results (shard 5)

    4 files      4 suites   1m 53s ⏱️
1 503 tests 1 503 ✅ 0 💤 0 ❌
1 504 runs  1 504 ✅ 0 💤 0 ❌

Results for commit c08fee1.

[github-actions]

Test Results (shard 4)

2 316 tests   2 316 ✅  2m 26s ⏱️
    3 suites      0 💤
    3 files        0 ❌

Results for commit c08fee1.

[github-actions]

Test Results (shard 2)

588 tests   396 ✅  2m 56s ⏱️
  3 suites  192 💤
  3 files      0 ❌

Results for commit c08fee1.

[github-actions]

Test Results

   15 files     15 suites   10m 55s ⏱️
5 502 tests 5 308 ✅ 194 💤 0 ❌
5 503 runs  5 309 ✅ 194 💤 0 ❌

Results for commit c08fee1.

[rbuergi]

🚨 This withdrawal took core CD down, and the reason is one reference #1351 did not cover.

The reasoning here is right — the version belongs beside the reason, not in a central list this repo
does not consume. But the withdrawal removed four pins, and Plugins#1351 only replaced two:

pin withdrawn here	replaced in Plugins#1351?
SQLitePCLRaw.core 3.0.2	✅ VersionOverride="3.0.2"
SQLitePCLRaw.provider.e_sqlite3 3.0.2	✅ VersionOverride="3.0.2"
SQLitePCLRaw.bundle_e_sqlite3 3.0.2	n/a — deliberately not pinned
SQLitePCLRaw.lib.e_sqlite3 3.53.3	❌ nothing

MeshWeaver.Hosting.Sqlite.csproj carries a versionless
<PackageReference Include="SQLitePCLRaw.lib.e_sqlite3" /> — the CVE pin — and its version came from
exactly the central entry withdrawn here (Plugins' src/Directory.Packages.props imports this list
through $(MeshWeaverRoot)). So since this merged, every main-cd run has failed:

MeshWeaver.Hosting.Sqlite.csproj : error NU1010: The following PackageReference items do not define
  a corresponding PackageVersion item: SQLitePCLRaw.lib.e_sqlite3
Memex.Portal.Distributed.csproj  : error NU1903: Warning As Error: Package
  'SQLitePCLRaw.lib.e_sqlite3' 2.1.11 has a known high severity vulnerability, GHSA-2m69-gcr7-jv3q

NU1010 for the missing version, then NU1903 because the fallback resolution reintroduced the very
2.1.11 that pin existed to avoid — the "latent CVE regression" this commit message set out to
prevent, arriving by the other door.

ci.7813 and ci.7814 both SKIPPED Promote: tag the full set, so nothing has been published since
and no image exists for the Plugins pin bump (#1349/#1359) to move to. That is the live blast radius:
core CD produces nothing at all.

Fixed forward in Plugins#1361 — VersionOverride="3.53.3" on that reference, so it depends on
nothing outside its own repo. Verified on CD's own path (-p:MeshWeaverRoot=<core checkout>, which
is how CD builds the plugins tree): both projects restore clean, resolving lib.e_sqlite3/3.53.3
beside core/3.0.2, with bundle_e_sqlite3 left at 2.1.11 as your note requires. No revert needed
here — the withdrawal itself is correct.

Worth recording for next time, because neither repo's CI could see it: a versionless
PackageReference under Central Package Management is a cross-repo dependency, and withdrawing a
central pin is a breaking change to every versionless reference that resolved through it. The
Cross-repo pair (public surface) gate cannot see this shape — it watches public types and members,
not package-version resolution — so it is an eighth break shape for
CrossRepoPairGate.md. Plugins
CI compiles against the pinned IMAGE and never builds the portal host the way core CD does, so the
break could only ever surface here, one commit later.