Skip to content

Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506

Closed
#527
Closed
Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample#506
#527
Labels
Examples

Description

@adrianhall
adrianhall
opened on Jul 7, 2026

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

Activity

  1. adrianhall
    added
    Examples
    on Jul 7, 2026

  2. adrianhall commented on Jul 7, 2026

    @adrianhall
    adrianhall
    on Jul 7, 2026
    CollaboratorAuthor

    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.

  3. adrianhall
    added 3 commits that reference this issue on Jul 7, 2026

    ci: disable todoapp-uno job pending CommunityToolkit#506

    d7e68fc

    ci: add build-samples workflow for Phase 3 mobile heads (#511) (#519)

    bf21dc8

    ci: pin iOS workload set + Xcode version for todoapp-avalonia/maui iO…

    398792f
  4. adrianhall
    closed this as completedin cb34b91on Jul 10, 2026
  5. adrianhall
    added a commit that references this issue on Jul 10, 2026

    fix: resolve NU1605 blocking TodoApp.Uno restore by bumping Uno.Sdk t…

    cb34b91
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Examples

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions