Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample

[adrianhall]

Summary

Split out from #499 (now scoped to the Avalonia sample only). Restoring the Uno desktop-head sample on Linux/macOS surfaces a NU1903 high-severity restore warning:

warning NU1903: Package 'Tmds.DBus' 0.16.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xrw6-gwf8-vvr9

What's known so far

• Advisory: GHSA-xrw6-gwf8-vvr9 / CVE-2026-39959 — "malicious D-Bus peers can spoof signals, exhaust file descriptor resources, and cause denial of service". Patched version: Tmds.DBus 0.92.0 (fixes < 0.92.0).
• Repro: samples/todoapp/TodoApp.Uno/TodoApp.Uno/TodoApp.Uno.csproj (net10.0-desktop head) — dotnet restore floats Tmds.DBus 0.16.0.
• This restore attempt hit an unrelated, pre-existing NU1605 package-downgrade error (Uno.WinUI 5.5.87 vs 5.4.22, driven by a mismatch between global.json's Uno.Sdk version and CommunityToolkit.WinUI.Behaviors' floor), which blocks confirming the full Tmds.DBus 0.16.0 dependency chain. This needs to be resolved, or at least understood, first.
• Separately, there's an open question about bumping Uno itself from 5.4.5 to 6.6+ to pick up a non-vulnerable transitive version of this dependency — that's a larger migration effort and can be tracked as its own follow-up if a targeted fix here doesn't land cleanly.

Ask

Investigate one of:

1. Resolve the pre-existing Uno.WinUI NU1605 package-downgrade issue on TodoApp.Uno's desktop head, then re-check whether a compatible dependency bump already resolves Tmds.DBus to >= 0.92.0 (mirroring how Avalonia.FreeDesktop 11.3.18 already resolved the equivalent Avalonia-side finding — see Investigate resolving NU1903 for Tmds.DBus.Protocol in Avalonia desktop sample #499).
2. If not, add an explicit <PackageReference Include="Tmds.DBus" Version="0.92.0" /> (or later) override to TodoApp.Uno's desktop head, mirroring the SQLitePCLRaw.bundle_e_sqlite3 override pattern used in fix: resolve NU1903 for SQLitePCLRaw.lib.e_sqlite3 by pinning SQLitePCLRaw 3.x #498.
3. Confirm whether Tmds.DBus is reachable code (Linux D-Bus paths) in the Uno desktop sample at all before deciding this is worth a version bump vs. just documenting/suppressing.
4. Consider whether this should be folded into a broader Uno 5.4.5 → 6.6+ major-version-bump effort instead of a standalone patch, if that migration is going to happen soon anyway.

Related

• Investigate resolving NU1903 for Tmds.DBus.Protocol in Avalonia desktop sample #499 — sibling issue, now scoped to the Avalonia sample's equivalent Tmds.DBus.Protocol finding (resolved via an 11.3.x patch bump, no major-version bump needed).
• Investigate resolving NU1903 for SQLitePCLRaw.lib.e_sqlite3 (no patched version exists) #492 / fix: resolve NU1903 for SQLitePCLRaw.lib.e_sqlite3 by pinning SQLitePCLRaw 3.x #498 — original NU1903 investigation (SQLitePCLRaw.lib.e_sqlite3) where this whole family of findings originated.

[adrianhall]

Update from #511 / PR #519 CI

While implementing #511 (Phase 3 samples CI), I built out a build-samples-todoapp-uno.yml workflow with a job per Uno head (android, ios, maccatalyst, windows, browserwasm, desktop). CI confirmed the NU1605 reported in this issue is not desktop-specific - it fails restore on every head, since CommunityToolkit.WinUI.Behaviors's PackageReference in TodoApp.Uno.csproj is unconditional (not scoped to any single TFM).

Confirmed reproduction

CI log (android TFM, ubuntu-latest):

Run dotnet restore samples/todoapp/TodoApp.Uno/TodoApp.Uno/TodoApp.Uno.csproj -p:TargetFramework=net10.0-android
  Determining projects to restore...
.../TodoApp.Uno.csproj : warning NU1510: PackageReference System.Formats.Asn1 will not be pruned. ... [TargetFramework=net10.0-android]
.../TodoApp.Uno.csproj : warning NU1510: PackageReference System.Private.Uri will not be pruned. ... [TargetFramework=net10.0-android]
.../TodoApp.Uno.csproj : warning NU1510: PackageReference System.Text.Json will not be pruned. ... [TargetFramework=net10.0-android]
.../TodoApp.Uno.csproj : error NU1605: Warning As Error: Detected package downgrade: Uno.WinUI from 5.5.87 to 5.4.22. Reference the package directly from the project to select a different version.  [TargetFramework=net10.0-android]
.../TodoApp.Uno.csproj : error NU1605:  TodoApp.Uno -> CommunityToolkit.WinUI.Behaviors 8.2.250402 -> Uno.WinUI (>= 5.5.87)  [TargetFramework=net10.0-android]
.../TodoApp.Uno.csproj : error NU1605:  TodoApp.Uno -> Uno.WinUI (>= 5.4.22) [TargetFramework=net10.0-android]
  Failed to restore .../TodoApp.Uno.csproj (in 9.84 sec).

Also reproduced locally (dotnet restore samples/todoapp/TodoApp.Uno/TodoApp.Uno/TodoApp.Uno.csproj -p:TargetFramework=net10.0-desktop, no workload needed for this TFM) - identical NU1605, plus the original NU1903 (Tmds.DBus 0.16.0) warning this issue was filed for:

.../TodoApp.Uno.csproj : warning NU1903: Package 'Tmds.DBus' 0.16.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xrw6-gwf8-vvr9 [TargetFramework=net10.0-desktop]
.../TodoApp.Uno.csproj : error NU1605: Warning As Error: Detected package downgrade: Uno.WinUI from 5.5.87 to 5.4.22. ... [TargetFramework=net10.0-desktop]

Confirmed: the NU1903 warning is not currently a CI blocker on its own

This repo doesn't configure NuGet audit to fail builds anywhere (no NuGetAuditMode/WarningsAsErrors overrides in any Directory.Build.props/Directory.Packages.props), so the Tmds.DBus NU1903 warning by itself would not fail restore/build. The NU1605 is what actually blocks every head - it's a restore-time error by default, not a warning.

Root cause

• global.json pins Uno.Sdk to 5.4.5, which resolves the implicit Uno.WinUI package to 5.4.22.
• Directory.Packages.props pins CommunityToolkit.WinUI.Behaviors to 8.2.250402, whose dependency floor requires Uno.WinUI >= 5.5.87.
• Since CommunityToolkit.WinUI.Behaviors is referenced without any TFM condition, this conflict surfaces for every head's restore, not just desktop/windows.

Impact on #511 / PR #519

I've disabled the todoapp-uno job in build-samples.yml's orchestrator for now (commented out, not deleted) so PR #519 (the rest of Phase 3: Avalonia Android/iOS, MAUI Android/iOS) can land clean. The build-samples-todoapp-uno.yml file itself is already fully built out (one job per head, TFM-scoped restore/build) and just needs to be re-added to the orchestrator once this issue is resolved.

Suggested fix directions (for whoever picks this up)

1. Bump Uno.Sdk in global.json past whatever version resolves Uno.WinUI to >= 5.5.87 (confirm this doesn't require other coordinated bumps for Uno's companion packages).
2. Or find/pin a CommunityToolkit.WinUI.Behaviors version whose floor is compatible with Uno.WinUI 5.4.22 (may need a downgrade from 8.2.250402).
3. Or explicitly pin Uno.WinUI in Directory.Packages.props to >= 5.5.87 via central package management, overriding the SDK's implicit version - lowest-touch option, but carries some risk of drifting from whatever companion package versions Uno.Sdk 5.4.5 otherwise expects to travel together.

Once one of these gets TodoApp.Uno.csproj restoring cleanly for at least one head, I (or whoever picks this up) can re-enable todoapp-uno in build-samples.yml and confirm the rest of the heads in CI.