Problem
Source-build applies a patch that reverts the IdentityModel 8.19.2 Microsoft.Bcl.Cryptography and ML-DSA update:
https://github.com/dotnet/source-build-assets/blob/07e5dbddc0154145ed167c08fdedcc64e0e5613b/src/externalPackages/patches/azure-activedirectory-identitymodel-extensions-for-dotnet/0001-Revert-10.0-BCL.Crypto-update.patch
This causes the source-built dotnet-user-jwts tool to differ from the Microsoft-built tool:
Microsoft.Bcl.Cryptography.dll is absent.
Microsoft.IdentityModel.Tokens.dll lacks the ML-DSA APIs.
- SDK diff tests require file and API suppressions.
Proposed Approach
Remove the IdentityModel revert patch while preserving the 1xx source-build ordering:
- Build IdentityModel in source-build-assets against the N-1 previously source-built
Microsoft.Bcl.Cryptography package. At this point, the current runtime package has not yet been built.
- Allow runtime to produce the current
Microsoft.Bcl.Cryptography package.
- When ASP.NET Core later builds
dotnet-user-jwts, add a direct source-build dependency on Microsoft.Bcl.Cryptography at $(MicrosoftNETCoreAppRefPackageVersion).
- Ensure the direct dependency overrides IdentityModel’s lower transitive version so the current-build runtime package is included in the tool payload.
ASP.NET Core already depends on runtime, so the current package is available before dotnet-user-jwts is restored and packed.
This is necessary because allowing NuGet to resolve IdentityModel’s >= 10.0.2 dependency normally could select the lower N-1 PSB version. Since dotnet-user-jwts redistributes its transitive runtime assets, that would leak the poisoned PSB assembly into the final SDK.
Implementation Notes
The ASP.NET Core reference should follow its existing dependency-resolution conventions:
- Register
Microsoft.Bcl.Cryptography as a latest package dependency.
- Add a direct reference from
dotnet-user-jwts, gated to source-build if appropriate.
- Override its source-build version to
$(MicrosoftNETCoreAppRefPackageVersion) through the VMR package-version properties.
The existing EF Core source-build overrides in repo-projects/aspnetcore.proj provide a similar pattern.
Problem
Source-build applies a patch that reverts the IdentityModel 8.19.2
Microsoft.Bcl.Cryptographyand ML-DSA update:https://github.com/dotnet/source-build-assets/blob/07e5dbddc0154145ed167c08fdedcc64e0e5613b/src/externalPackages/patches/azure-activedirectory-identitymodel-extensions-for-dotnet/0001-Revert-10.0-BCL.Crypto-update.patch
This causes the source-built
dotnet-user-jwtstool to differ from the Microsoft-built tool:Microsoft.Bcl.Cryptography.dllis absent.Microsoft.IdentityModel.Tokens.dlllacks the ML-DSA APIs.Proposed Approach
Remove the IdentityModel revert patch while preserving the 1xx source-build ordering:
Microsoft.Bcl.Cryptographypackage. At this point, the current runtime package has not yet been built.Microsoft.Bcl.Cryptographypackage.dotnet-user-jwts, add a direct source-build dependency onMicrosoft.Bcl.Cryptographyat$(MicrosoftNETCoreAppRefPackageVersion).ASP.NET Core already depends on runtime, so the current package is available before
dotnet-user-jwtsis restored and packed.This is necessary because allowing NuGet to resolve IdentityModel’s
>= 10.0.2dependency normally could select the lower N-1 PSB version. Sincedotnet-user-jwtsredistributes its transitive runtime assets, that would leak the poisoned PSB assembly into the final SDK.Implementation Notes
The ASP.NET Core reference should follow its existing dependency-resolution conventions:
Microsoft.Bcl.Cryptographyas a latest package dependency.dotnet-user-jwts, gated to source-build if appropriate.$(MicrosoftNETCoreAppRefPackageVersion)through the VMR package-version properties.The existing EF Core source-build overrides in
repo-projects/aspnetcore.projprovide a similar pattern.