Skip to content

Remove IdentityModel BCL.Cryptography revert patch from source-build #5626

Description

@mthalman

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:

  1. 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.
  2. Allow runtime to produce the current Microsoft.Bcl.Cryptography package.
  3. When ASP.NET Core later builds dotnet-user-jwts, add a direct source-build dependency on Microsoft.Bcl.Cryptography at $(MicrosoftNETCoreAppRefPackageVersion).
  4. 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.

Metadata

Metadata

Assignees

Labels

area-buildImprovements in source-build's own build process

Type

No type

Projects

Status
In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions