deps: Bump SQLitePCLRaw.bundle_e_sqlite3 from 2.1.12 to 3.0.4

[dependabot]

Updated SQLitePCLRaw.bundle_e_sqlite3 from 2.1.12 to 3.0.4.

Release notes

Sourced from SQLitePCLRaw.bundle_e_sqlite3's releases.

3.0.4

Update SQLitePCLRaw.bundle_e_sqlite3 to reference SourceGear.sqlite3 version 3.53.3.

3.0.3

Fixes for some fairly obscure memory corruption bugs, thanks for PR #​663 and related

3.0.2

Update SourceGear.lib dependency to 3.50.4.2

3.0.1

• Change package ID of SQLitePCLRaw.lib.e_sqlite3 to SourceGear.sqlite3
• Minor changes to readmes and such

3.0.0

v3 release notes

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[erikdarlingdata]

Summary

Dependabot bump of SQLitePCLRaw.bundle_e_sqlite3 from 2.1.12 → 3.0.4 in server/PlanShare/PlanShare.csproj. One-line change.

What's good

• Direct ref is still the right shape while Microsoft.Data.Sqlite floors below 2.1.12; the bump keeps the CVE-2025-6965 mitigation intact and moves further ahead.
• Dependabot config correctly keeps majors out of the patch-and-minor group, so this arrived as its own PR rather than buried in a batch — that's working as intended.

Needs attention

1. Base branch is main, not dev. The repo's active development branch is dev (protected, per list-branches) and other feature PRs on this repo target dev. .github/dependabot.yml has no target-branch: set, so every Dependabot PR defaults to the repo default (main) — #406 has the same problem. Either retarget this PR to dev before merging, or add target-branch: dev under each updates: block in .github/dependabot.yml so future bumps land on the right branch. Flagging this on every Dependabot PR until the config is fixed is going to get noisy.

2. Major version bump on a native-bundle package. See inline on PlanShare.csproj:14. The managed API of bundle_e_sqlite3 is stable across the 2→3 jump but the underlying package graph changed (SQLitePCLRaw.lib.e_sqlite3 → SourceGear.sqlite3) and the native binary moved to SQLite 3.53.3. Worth a runtime smoke of PlanShare on Linux/macOS/Windows before merge — CI restore + build passing isn't sufficient for a native-asset bump.

3. Stale rationale comment. L11–13 argue for the direct ref in terms of a CVE fix at 2.1.12 and "remove this once its floor reaches 2.1.12+". After this bump the comment reads as an argument to delete the pin, which would regress the version. Rewrite the intent if this lands.

No PlanAnalyzer changes, no Avalonia/XAML changes, no src/ logic changes — none of the Studio-specific gotchas apply.

Not approving / not requesting changes — comments only.

---

Generated by Claude Code

[erikdarlingdata]

This is a major version bump (2.1.12 → 3.0.4) on a package that ships the native SQLite binary. Per the upstream v3 release notes the package ID of SQLitePCLRaw.lib.e_sqlite3 was renamed to SourceGear.sqlite3 and the bundled native was moved to SourceGear.sqlite3 3.53.3, so restore/lock/pack outputs will change even though the managed API surface for bundle_e_sqlite3 is stable. Worth a manual smoke of PlanShare against a real SQLite DB on every OS you ship (esp. Linux, where native-asset RIDs regress most often — see the SkiaSharp pin in .github/dependabot.yml).

The rationale comment on L11–13 is now stale: the CVE-2025-6965 mitigation reason no longer describes intent (we're far past 2.1.12), and "remove this once its floor reaches 2.1.12+" would now argue for removing the direct ref, which would silently drop us back to whatever transitive Microsoft.Data.Sqlite carries (still 2.1.11 per that comment). If this bump lands, rewrite the comment to state the new intent — pinning to 3.x ahead of Microsoft.Data.Sqlite — otherwise a future cleanup will delete the ref for the wrong reason.

---

Generated by Claude Code

[erikdarlingdata]

Verified this beyond a green build, since the real risk here is runtime rather than compile-time.

Microsoft.Data.Sqlite 10.0.10 floors its transitive SQLitePCLRaw at 2.1.11, so moving the direct ref to the 3.x major could plausibly break provider registration - and that would fail at runtime, not at build.

What I tested

Built PlanShare on 3.0.4, ran the actual binary, and exercised every SQL path in Program.cs against a throwaway database:

Step	Exercises	Result
GET /api/stats	SELECT + COUNT/COUNT(DISTINCT) aggregates	200, correct empty-state JSON
POST /api/share	INSERT	200, returned id + delete_token
GET /api/plans/{id}	SELECT round-trip	returned the exact stored payload
DELETE /api/plans/{id}?token=	parameterized DELETE	200
GET after delete	expiry/absence path	404

No provider registration failure, no runtime error.

CVE status holds

3.0.4 bundles SQLite 3.53.3, well past the 3.50.2 that fixes CVE-2025-6965. So this keeps the fix that the original 2.1.12 pin was added for.

One extra commit

I updated the comment above the ref. It said "remove this once its floor reaches 2.1.12+", which is stale now the ref is on the 3.x line - and misleading, because Microsoft.Data.Sqlite still floors at the vulnerable 2.1.11, so this direct ref remains the thing keeping the native library patched. Deleting it on the strength of the old comment would silently reintroduce the CVE.

Note on deployment

server/PlanShare/** now has an auto-deploy workflow (#399) that fires on push to main. So this will actually reach the running server on the next release, rather than sitting in source the way the previous PlanShare fixes did for 3.5 months.

[claude]

Reviewed. This is a minimal, low-risk dependency bump (2 lines in PlanShare.csproj), already merged.

• No direct SQLitePCLRaw API usage anywhere else in the repo (verified via grep) — it's only pulled in as a direct ref to lift the transitive floor above the CVE-2025-6965 vulnerable version, so the 2.x→3.x major bump carries no call-site risk.
• The updated comment correctly explains the rationale and claims CRUD was manually verified against the 3.x native layer — reasonable given this touches SQLite's native binding.
• Nothing here touches T-SQL generation, plan-XML parsing, or the PlanViewer.Ssms/Blazor linked-file conventions this repo cares about, so those checks don't apply.

No issues found.