fix: resolve NU1605 blocking TodoApp.Uno restore by bumping Uno.Sdk to 5.6.54#527
Open
adrianhall wants to merge 1 commit into
Open
fix: resolve NU1605 blocking TodoApp.Uno restore by bumping Uno.Sdk to 5.6.54#527adrianhall wants to merge 1 commit into
adrianhall wants to merge 1 commit into
Conversation
…o 5.6.54 (CommunityToolkit#506) CommunityToolkit.WinUI.Behaviors 8.2.250402 (pinned in samples/todoapp/TodoApp.Uno/Directory.Packages.props) floors Uno.WinUI at >= 5.5.87, but Uno.Sdk 5.4.5 (the previous global.json pin) resolves Uno.WinUI to 5.4.22, causing a NU1605 package-downgrade restore error on every head (android, ios, maccatalyst, windows, browserwasm, desktop) - not just the desktop head CommunityToolkit#506 originally reported. Bump Uno.Sdk in samples/todoapp/TodoApp.Uno/global.json from 5.4.5 to 5.6.54 (the latest stable 5.x release), which resolves Uno.WinUI to 5.6.99, clearing the floor. Confirmed via 'dotnet restore' that NU1605 is gone on the desktop, windows, and browserwasm heads (android/ios/ maccatalyst require workloads not available in this environment). This does NOT resolve the original NU1903 finding (Tmds.DBus 0.16.0, GHSA-xrw6-gwf8-vvr9) - Uno.WinUI.Runtime.Skia.X11 keeps floating vulnerable Tmds.DBus 0.16.0 through the entire 5.x line and only switches to the patched Tmds.DBus.Protocol starting at Uno.WinUI 6.0.465, which requires a major-version bump. Filed as a follow-up: CommunityToolkit#524. Restoring cleanly also surfaced two more pre-existing, unrelated issues that were previously masked by NU1605 (never surfaced because no head ever restored successfully before): - Every Skia-based head (desktop, browserwasm, and almost certainly android/ios/maccatalyst) fails to BUILD with UXAML0001 (EventTriggerBehavior could not be found), because CommunityToolkit.WinUI.Behaviors resolves a dev-prerelease Uno.Microsoft.Xaml.Behaviors.Interactivity.WinUI package on those heads instead of the real Microsoft.Xaml.Behaviors.WinUI.Managed package (which the windows head still gets). Filed as a follow-up: CommunityToolkit#525. - The browserwasm head surfaces two more NU1903 findings for System.Security.Cryptography.Xml 8.0.2. Filed as a follow-up: CommunityToolkit#526. Given the above, the todoapp-uno CI job (build-samples-todoapp-uno.yml) is intentionally left unwired in build-samples.yml for now - re-enabling it today would turn all-samples-built red on every PR due to CommunityToolkit#525. Updated the NOTE comments in both workflow files to reflect the new state. Fixes CommunityToolkit#506
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
Resolves the NU1605 restore blocker for #506.
CommunityToolkit.WinUI.Behaviors 8.2.250402(pinned insamples/todoapp/TodoApp.Uno/Directory.Packages.props) floorsUno.WinUIat>= 5.5.87, butUno.Sdk 5.4.5(the previousglobal.jsonpin) resolvesUno.WinUIto5.4.22, causing:on every head (android, ios, maccatalyst, windows, browserwasm, desktop) - not just the desktop head #506 originally reported (confirmed in this comment).
Changes
Uno.Sdkinsamples/todoapp/TodoApp.Uno/global.jsonfrom5.4.5to5.6.54(the latest stable 5.x release), which resolvesUno.WinUIto5.6.99, clearing the>= 5.5.87floor. Confirmed via nupkg/nuspec inspection that this is the smallest Uno.Sdk change that stays within the current major version (avoids the larger 6.x migration effort called out in Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506).build-samples.ymlandbuild-samples-todoapp-uno.ymlto reflect the new state.What this does NOT resolve
Tmds.DBus0.16.0, GHSA-xrw6-gwf8-vvr9) that Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506 was filed for.Uno.WinUI.Runtime.Skia.X11floats vulnerableTmds.DBus 0.16.0unchanged through the entire 5.x line (confirmed at 5.4.22, 5.5.87, 5.5.95, 5.6.99) and only switches to the patchedTmds.DBus.Protocolstarting at Uno.WinUI 6.0.465 - a major-version bump. Filed as a follow-up: Major-version bump: Uno Platform 5 -> 6 (TodoApp.Uno sample) #524.CommunityToolkit.WinUI.Behaviorsresolves a dev-prereleaseUno.Microsoft.Xaml.Behaviors.Interactivity.WinUIpackage on those heads (instead of the realMicrosoft.Xaml.Behaviors.WinUI.Managed, which thewindowshead still gets), which appears to be missing theMicrosoft.Xaml.Interactions.Coretypes used inViews/TodoListPage.xaml, causingUXAML0001/CS1061build errors. This was never surfaced before because restore always failed first. Filed as a follow-up: TodoApp.Uno fails to build on Skia heads: EventTriggerBehavior could not be found #525.System.Security.Cryptography.Xml8.0.2) surfaced on thebrowserwasmhead restore, also previously masked by NU1605. Filed as a follow-up: Investigate resolving NU1903 for System.Security.Cryptography.Xml in Uno browserwasm sample head #526.Given the above, the
todoapp-unoCI job (build-samples-todoapp-uno.yml) is intentionally left unwired inbuild-samples.yml- re-enabling it today would turnall-samples-builtred on every future PR due to #525's build failure. It should be re-wired once #525 (at minimum) is resolved.Validation
dotnet restore samples/todoapp/TodoApp.Uno/TodoApp.Uno/TodoApp.Uno.csproj -p:TargetFramework=net10.0-desktop- succeeds, NU1605 gone, NU1903 (Tmds.DBus) warning still present as expected/documented.dotnet restore ... -p:TargetFramework=net10.0-windows10.0.26100- succeeds cleanly, no NU1903 warnings (resolves the realMicrosoft.Xaml.Behaviors.WinUI.Managed).dotnet restore ... -p:TargetFramework=net10.0-browserwasm- succeeds, surfaces the twoSystem.Security.Cryptography.XmlNU1903 findings noted above (Investigate resolving NU1903 for System.Security.Cryptography.Xml in Uno browserwasm sample head #526).dotnet build ... -f net10.0-desktop- fails with the pre-existingEventTriggerBehaviorbug (TodoApp.Uno fails to build on Skia heads: EventTriggerBehavior could not be found #525), unrelated to this change.android/ios/maccatalystlocally (missingandroid/ios/maccatalystworkloads in this environment) - same limitation noted in PR fix: resolve NU1903 for Tmds.DBus.Protocol in Avalonia sample by bumping to 11.3.18 #508 for the Avalonia sample.dotnet build Datasync.Toolkit.sln --configuration Release(root solution, unaffected by this samples-only change) - succeeds, 0 warnings, 0 errors.Follow-ups filed
Tmds.DBusNU1903 finding.EventTriggerBehaviorbuild failure on Skia heads, blocking CI re-enablement.System.Security.Cryptography.XmlNU1903 finding on the browserwasm head.Fixes #506