fix: resolve remaining sample package drift and Microsoft.OpenApi NU1903#493
Merged
Merged
Conversation
…903 (CommunityToolkit#489) - Bump samples/todoapp-mvc Microsoft.EntityFrameworkCore.SqlServer 10.0.3 -> 10.0.9 to match the repo's EFCoreVersion (missed in CommunityToolkit#485). - Bump stray Microsoft.AspNetCore.Components.WebAssembly*/Microsoft.Extensions.Http pins in todoapp-blazor-wasm from 10.0.3 -> 10.0.9. - Bump Microsoft.EntityFrameworkCore (Avalonia), Microsoft.Extensions.Logging.Debug (MAUI), Microsoft.Extensions.DependencyInjection (WinUI3), and System.Text.Json/System.Formats.Asn1/System.IO.Packaging (Uno, local CPM) from 10.0.3 -> 10.0.9 across the todoapp client-platform samples. - Bump CommunityToolkit.Datasync.Client 10.0.0 -> 10.1.0 across every client sample (Avalonia, MAUI, Uno, WPF, WinUI3, todoapp-tutorial/ClientApp, todoapp-blazor-wasm/Client) to match the latest published package, alongside the already-updated 10.1.0 server samples. - Pin Microsoft.OpenApi to 2.7.5 in root Directory.Packages.props to resolve the NU1903 high-severity advisory (GHSA-v5pm-xwqc-g5wc) on the 2.0.0 version floated transitively via Microsoft.AspNetCore.OpenApi/NSwag.AspNetCore/ Swashbuckle.AspNetCore. CentralPackageTransitivePinningEnabled propagates this through project references into samples/datasync-server and samples/datasync-server-cosmosdb-singlecontainer without needing per-sample pins; verified every restored project.assets.json in the repo now resolves Microsoft.OpenApi/2.7.5. The remaining NU1903 advisory (SQLitePCLRaw.lib.e_sqlite3, GHSA-2m69-gcr7-jv3q) has no patched version available and is tracked separately in CommunityToolkit#492. Verified: dotnet restore/build/test on Datasync.Toolkit.sln (2280+ tests passing across all suites), plus restore+build for every affected sample solution/project (todoapp-mvc, todoapp-blazor-wasm, datasync-server, datasync-server-cosmosdb-singlecontainer, todoapp-tutorial, TodoApp.Avalonia, TodoApp.Avalonia.Desktop, TodoApp.WPF). TodoApp.MAUI/TodoApp.Uno mobile TFMs and TodoApp.WinUI3 build could not be fully exercised in this environment due to missing Android/iOS/Windows workloads, but package restore succeeded up to that point, confirming the version pins resolve cleanly.
adrianhall
added a commit
that referenced
this pull request
Jul 6, 2026
…CLRaw 3.x (#498) * fix: resolve NU1903 for SQLitePCLRaw.lib.e_sqlite3 by pinning SQLitePCLRaw 3.x (#492) Microsoft.EntityFrameworkCore.Sqlite floats a transitive dependency on SQLitePCLRaw.bundle_e_sqlite3 2.1.11, which pulls in the deprecated SQLitePCLRaw.lib.e_sqlite3 2.1.11 and triggers NU1903 (GHSA-2m69-gcr7-jv3q / CVE-2025-6965 - SQLite versions before 3.50.2 have a memory corruption issue). The advisory says no patched version exists for lib.e_sqlite3, but the SQLitePCLRaw 3.x line (released after the advisory) drops lib.e_sqlite3 entirely and depends on SourceGear.sqlite3 3.50.4.5 instead (SQLite 3.50.4, above the fix line), with full runtime asset coverage for android, ios, maccatalyst, browser-wasm, linux (incl. musl), osx, and win RIDs. - Pin SQLitePCLRaw.bundle_e_sqlite3 to 3.0.3 in the root Directory.Packages.props. CentralPackageTransitivePinningEnabled propagates this into src/CommunityToolkit.Datasync.Client, tests/CommunityToolkit.Datasync.TestCommon, tests/CommunityToolkit.Datasync.TestService, and tests/CommunityToolkit.Datasync.Client.Test without needing an explicit PackageReference, mirroring the Microsoft.OpenApi NU1903 fix from #489. - This does not affect the main packages' own published dependency floor, so every sample that consumes CommunityToolkit.Datasync.Client via NuGet PackageReference still floats the vulnerable version on its own. Added the same explicit override to the 7 affected samples: TodoApp.Avalonia, TodoApp.MAUI, TodoApp.WPF, TodoApp.WinUI3, TodoApp.Uno (via its own local Directory.Packages.props), todoapp-tutorial/ClientApp, and todoapp-blazor-wasm/TodoApp.BlazorWasm.Client. - TodoApp.Avalonia.Desktop needs no change; it inherits the pin transitively via its ProjectReference to TodoApp.Avalonia (verified via restore). Verified: dotnet restore/build/test on Datasync.Toolkit.sln (2280 tests passing across all 12 suites, 0 warnings on build). Confirmed every restored project.assets.json in src/tests now resolves SQLitePCLRaw.bundle_e_sqlite3/3.0.3 with zero occurrences of sqlitepclraw.lib.e_sqlite3 anywhere in the graph. Also verified restore (and build where the target platform doesn't require a missing workload) for TodoApp.Avalonia, TodoApp.Avalonia.Desktop, TodoApp.BlazorWasm.Client, todoapp-tutorial/ClientApp, TodoApp.WPF, and TodoApp.WinUI3 -- all clean, no NU1903, SQLitePCLRaw resolves to 3.0.3. TodoApp.MAUI (net10.0-android) and TodoApp.Uno's mobile TFMs could not be restored in this environment due to missing Android/iOS workloads, the same limitation noted in #493; the package-version pin is applied identically and is expected to resolve cleanly once those workloads are available, same as every other affected project. Fixes #492 * docs: document the SQLitePCLRaw NU1903 fix and fix a broken admonition title - Add a note under 'Creating an offline-capable DbContext' in docs/in-depth/client/index.md pointing consumers at the SQLitePCLRaw.bundle_e_sqlite3 3.0.3 override from #492/#498 if they hit the NU1903 audit warning in their own application. - Fix the 'Blazor WASM and Blazor Hybrid' admonition above that section: it used an unquoted, bold (**...**) title (!!! note **Blazor WASM and Blazor Hybrid**), which the admonition markdown extension's title regex does not accept -- the whole block silently failed to parse as an admonition and rendered as a plain paragraph with literal '!!! note' text. Quoting the title (!!! note "Blazor WASM and Blazor Hybrid") fixes it. Verified against python-markdown + pymdownx.superfences (the extensions configured in mkdocs.shared.yml) that both admonitions now render as proper admonition blocks, including the nested fenced xml code sample. * docs: fix a second broken admonition title in client index.md !!! warning DO NOT USE THE SAME ENTITY TYPE FOR BOTH SERVICE AND CLIENT used an unquoted, all-caps multi-word title. The admonition extension's title regex swallows unquoted words into the block's CSS class list instead of using them as the title, so this rendered with the generic 'Warning' title (its intended custom title was silently dropped) and polluted the div's class attribute with lowercased title words. Quoting the title fixes both problems. Verified against python-markdown + pymdownx.superfences (the extensions configured in mkdocs.shared.yml): now renders as <div class="admonition warning"> with the correct custom title. * docs: add 'Building the documentation site' section to README Documents how to build/serve the MkDocs site locally (python venv, mkdocs + mkdocs-mermaid2-plugin, mkdocs serve on localhost:7000, and mkdocs build for a static site). Also add .venv-*/ to .gitignore so a local docs venv isn't accidentally committed. --------- Co-authored-by: ahall <ahall@cloudflare.com>
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.
Summary
Addresses the remaining unresolved items from #489 (the earlier sample fixes for
datasync-server,datasync-server-cosmosdb-singlecontainer, and most oftodoapp-blazor-wasm/todoapp-mvcwere already merged in #488/#490/#491).Package version drift fixes
samples/todoapp-mvc:Microsoft.EntityFrameworkCore.SqlServer10.0.3 → 10.0.9(missed in docs: document secure UnsafeEntityLogging default in todoapp-mvc sample #485; same drift class as docs: document secure UnsafeEntityLogging default in datasync-server sample (#477) #488).samples/todoapp-blazor-wasm: strayMicrosoft.AspNetCore.Components.WebAssembly*/Microsoft.Extensions.Http10.0.3 → 10.0.9.samples/todoappclient platforms (Avalonia, MAUI, WPF, WinUI3, Uno):10.0.3 → 10.0.9onMicrosoft.EntityFrameworkCore,Microsoft.Extensions.Logging.Debug,Microsoft.Extensions.DependencyInjection,System.Text.Json/Formats.Asn1/IO.Packaging.CommunityToolkit.Datasync.Client10.0.0 → 10.1.0everywhere it's referenced (Avalonia, MAUI, Uno, WPF, WinUI3,todoapp-blazor-wasm/Client,todoapp-tutorial/ClientApp) to match the latest published package, bringing it in line with the server samples already on 10.1.0.All values were checked against the root
Directory.Packages.props(DotNetVersion/EFCoreVersion=10.0.9) and the latest publishedCommunityToolkit.Datasync.*NuGet versions.NU1903 — Microsoft.OpenApi (GHSA-v5pm-xwqc-g5wc)
Pinned
Microsoft.OpenApito the patched2.7.5release in rootDirectory.Packages.props. BecauseCentralPackageTransitivePinningEnabledis alreadytruethere, this propagates throughProjectReferences intosamples/datasync-serverandsamples/datasync-server-cosmosdb-singlecontainerwithout needing a per-sample override — verified everyproject.assets.jsonin the repo now resolvesMicrosoft.OpenApi/2.7.5, with zero remaining2.0.0resolutions.NU1903 — SQLitePCLRaw.lib.e_sqlite3 (GHSA-2m69-gcr7-jv3q)
No patched version exists for this package (confirmed via the advisory and NuGet — the package is deprecated with no newer release). Filed #492 to track investigating this separately (potential suppression, migration off the EF Core Sqlite provider, or an alternate package) rather than bundling a bigger change into this PR.
Not in scope for this PR
Per discussion on #489, a CI/script-based drift-prevention mechanism was intentionally not added here — this is a one-time cleanup pass, not an ask for ongoing automation.
Verification
dotnet restore/dotnet build/dotnet testonDatasync.Toolkit.sln: build succeeded, all test suites passed (Server, Client, EFCore, CosmosDb, MongoDB, LiteDb, InMemory, Automapper, NSwag, OpenApi, Swashbuckle test projects — 0 failures).dotnet restore+dotnet buildconfirmed clean for:todoapp-mvc,todoapp-blazor-wasm,datasync-server,datasync-server-cosmosdb-singlecontainer,todoapp-tutorial,TodoApp.Avalonia(+.Desktop),TodoApp.WPF.TodoApp.MAUI,TodoApp.Uno(mobile TFMs), andTodoApp.WinUI3's full build could not be exercised on this (macOS, no Android/iOS/Windows workloads) machine, butdotnet restoregot past all package-version resolution before hitting the workload-not-installed check, confirming the version pins themselves resolve cleanly.Related