TypeLoadException in System.Security.Cryptography.Xml v7.0.0.0 for EncryptedData in .NET 4.8 project referencing .NET Standard 2.0 library

[mike-loux-planview]

Description

Upgraded System.Security.Cryptography.Xml v5.0.0 to v7.0.0 in a .NET 4.8 project, and now when I try to access the EncryptedData class, I get the following error:

System.TypeLoadException: Could not load type 'System.Security.Cryptography.Xml.EncryptedData' from assembly 'System.Security.Cryptography.Xml, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

Issue_System.Security.Cryptography.Xml.zip

Reproduction Steps

• Open Visual Studio 2022
• Create a .NET 4.8 console app.
• Add a .NET Standard 2.0 class library
• In the library:
  • Reference the System.Security.Cryptography.Xml NuGet package v7.0.0.0 (this also occurs in 6.0.0.1, FWIW).
  • Create a public class with a single method.
  • In the method, new up an instance of EncryptedData
• In the console app:
  • Ensure the <RestoreProjectStyle>PackageReference</RestoreProjectStyle> line is added to the .csproj file so you don't have to reference the NuGet package explicitly here.
  • Reference the class library, above.
  • In Main, new up an instance of the test class, above, and attempt to invoke the single method.

Expected behavior

Should not throw.

Actual behavior

I get the error mentioned in the description, above.

Regression?

This works fine when using System.Security.Encryption.Xml v6.0.1 or lower. As soon as you update to v7.0.0, BLAM.

Known Workarounds

Use v6.0.1 for now. The vulnerability appears to have been patched, but you don't get the v7.0.0 benefits (if there are any).

Configuration

• Console app is running on .NET 4.8
• Class library referencing the package is against .NET Standard 2.0
• Windows 10 Enterprise Version 21H2 (OS Build 19044.2251)
• Architecture is x64
• This has been reproduced on 2 separate machines running (roughly) the same configuration.

Other information

When looking at the .dll file using ILSpy or dotPeek, the EncryptedData class does not seem to be there at all.

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Upgraded System.Security.Cryptography.Xml v5.0.0 to v7.0.0 in a .NET 4.8 project, and now when I try to access the EncryptedData class, I get the following error:

System.TypeLoadException: Could not load type 'System.Security.Cryptography.Xml.EncryptedData' from assembly 'System.Security.Cryptography.Xml, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

Issue_System.Security.Cryptography.Xml.zip

Reproduction Steps

• Open Visual Studio 2022
• Create a .NET 4.8 console app.
• Add a .NET Standard 2.0 class library
• In the library:
  • Reference the System.Security.Cryptography.Xml NuGet package v7.0.0.0 (this also occurs in 6.0.0.1, FWIW).
  • Create a public class with a single method.
  • In the method, new up an instance of EncryptedData
• In the console app:
  • Ensure the <RestoreProjectStyle>PackageReference</RestoreProjectStyle> line is added to the .csproj file so you don't have to reference the NuGet package explicitly here.
  • Reference the class library, above.
  • In Main, new up an instance of the test class, above and attempt to invoke the single method.

Expected behavior

Should not throw.

Actual behavior

I get the error mentioned in the description, above.

Regression?

This works fine when using System.Security.Encryption.Xml v6.0.1 or lower. As soon as you update to v7.0.0, BLAM.

Known Workarounds

Use v6.0.1 for now. The vulnerability appears to have been patched, but you don't get the v7.0.0 benefits (if there are any).

Configuration

• Console app is running on .NET 4.8
• Class library referencing the package is against .NET Standard 2.0
• Windows 10 Enterprise Version 21H2 (OS Build 19044.2251)
• Architecture is x64
• This has been reproduced on 2 separate machines running (roughly) the same configuration.

Other information

When looking at the .dll file using ILSpy or dotPeek, the EncryptedData class does not seem to be there at all.

Author:	mike-loux-planview
Assignees:	-
Labels:	area-System.Security, untriaged
Milestone:	-

[bartonjs]

Looking at the assembly metadata for the 6.0.1 package's lib/net461 library:

...
 .permissionset reqmin
 = {[mscorlib]System.Security.Permissions.SecurityPermissionAttribute = {property bool 'SkipVerification' = bool(true)}}
 .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 // .$..............
 00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00 // .$..RSA1........
 4B 86 C4 CB 78 54 9B 34 BA B6 1A 3B 18 00 E2 3B // K...xT.4...;...;
 FE B5 B3 EC 39 00 74 04 15 36 A7 E3 CB D9 7F 5F // ....9.t..6....._
 04 CF 0F 85 71 55 A8 92 8E AA 29 EB FD 11 CF BB // ....qU....).....
 AD 3B A7 0E FE A7 BD A3 22 6C 6A 8D 37 0A 4C D3 // .;......"lj.7.L.
 03 F7 14 48 6B 6E BC 22 59 85 A6 38 47 1E 6E F5 // ...Hkn."Y..8G.n.
 71 CC 92 A4 61 3C 00 B8 FA 65 D6 1C CE E0 CB E5 // q...a<...e......
 F3 63 30 C9 A0 1F 41 83 55 9F 1B EF 24 CC 29 17 // .c0...A.U...$.).
 C6 D9 13 E3 A5 41 33 3A 1D 05 D9 BE D2 2B 38 CB ) // .....A3:.....+8.
 .hash algorithm 0x00008004
 .ver 6:0:0:1
}
.class extern forwarder System.Security.Cryptography.Xml.CipherData
{
 .assembly extern System.Security
}
.class extern forwarder System.Security.Cryptography.Xml.CipherReference
{
 .assembly extern System.Security
}
...

but in 7.0's lib/net462:

...
 .permissionset reqmin
 = {[mscorlib]System.Security.Permissions.SecurityPermissionAttribute = {property bool 'SkipVerification' = bool(true)}}
 .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 // .$..............
 00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00 // .$..RSA1........
 4B 86 C4 CB 78 54 9B 34 BA B6 1A 3B 18 00 E2 3B // K...xT.4...;...;
 FE B5 B3 EC 39 00 74 04 15 36 A7 E3 CB D9 7F 5F // ....9.t..6....._
 04 CF 0F 85 71 55 A8 92 8E AA 29 EB FD 11 CF BB // ....qU....).....
 AD 3B A7 0E FE A7 BD A3 22 6C 6A 8D 37 0A 4C D3 // .;......"lj.7.L.
 03 F7 14 48 6B 6E BC 22 59 85 A6 38 47 1E 6E F5 // ...Hkn."Y..8G.n.
 71 CC 92 A4 61 3C 00 B8 FA 65 D6 1C CE E0 CB E5 // q...a<...e......
 F3 63 30 C9 A0 1F 41 83 55 9F 1B EF 24 CC 29 17 // .c0...A.U...$.).
 C6 D9 13 E3 A5 41 33 3A 1D 05 D9 BE D2 2B 38 CB ) // .....A3:.....+8.
 .hash algorithm 0x00008004
 .ver 7:0:0:0
}
.mresource public FxResources.System.Security.Cryptography.Xml.SR.resources
{
 // Offset: 0x00000000 Length: 0x00002D64
}
.mresource public ILLink.Substitutions.xml
{
 // Offset: 0x00002D68 Length: 0x00000218
}
.module System.Security.Cryptography.Xml.dll
// MVID: {2E5B14BE-54BA-4A61-90C4-58C4ACDC69F1}
.custom instance void [mscorlib]System.Security.UnverifiableCodeAttribute::.ctor() = ( 01 00 00 00 ) 
.custom instance void System.Runtime.CompilerServices.RefSafetyRulesAttribute::.ctor(int32) = ( 01 00 0B 00 00 00 00 00 ) 
.imagebase 0x10000000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000009 // ILONLY
// Image base: 0x0000000000DC0000

(no forwards at all).

Digging through things, it looks like it got broken in #58011, because in

runtime/src/libraries/System.Security.Cryptography.Xml/ref/System.Security.Cryptography.Xml.csproj

Lines 7 to 10 in 8171bd0

	<ItemGroup>
	<Compile Include="System.Security.Cryptography.Xml.cs" Condition="'$(TargetFrameworkIdentifier)' != '.NETFramework'" />
	<Compile Include="System.Security.Cryptography.Xml.netframework.cs" Condition="'$(TargetFrameworkIdentifier)' == 'NETFramework'" />
	</ItemGroup>

the netframework.cs variant is only included if the TFI is NETFramework (no period), vs the main file (!= '.NETFramework', with a period). So the NETFX version of the reference assembly is empty, so the partial facade filled itself out by doing no work.

Looks like we need to add that period and republish the package. @ericstj / @jeffhandley what's our timing/process here?

[bartonjs]

I assume we didn't catch it because the tests directly include a reference to System.Security.dll:

runtime/src/libraries/System.Security.Cryptography.Xml/tests/System.Security.Cryptography.Xml.Tests.csproj

Lines 74 to 76 in 8171bd0

	<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework'">
	<Reference Include="System.Security" />
	</ItemGroup>

[mike-loux-planview]

Seriously cool watching someone else's CI/CD in action. Thanks for jumping on this so quickly, folks!
How long does it typically take for a new package (pre-release or otherwise) to drop?
This is obviously not critical, as we have a workaround, but I'm insanely curious.

[bartonjs]

How long does it typically take for a new package (pre-release or otherwise) to drop?

The daily builds from .NET 8 should already be available, but might yank your package graph forward in complicated ways (it also might not, I'm just offering it as a thing to watch out for):
https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md#obtaining-daily-builds-of-nuget-packages

The official package update from the v7 line should be on NuGet in January. We usually publish on Patch Tuesday, or close to it, so January 10th or thereabouts.

[ericstj]

We should do a root cause analysis as to why APICompat (Package Validation) didn't catch this. I would have expected it to flag the removed types compared to last release. cc @ViktorHofer @smasher164

[mike-loux-planview]

How long does it typically take for a new package (pre-release or otherwise) to drop?

The daily builds from .NET 8 should already be available, but might yank your package graph forward in complicated ways (it also might not, I'm just offering it as a thing to watch out for): https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md#obtaining-daily-builds-of-nuget-packages

The official package update from the v7 line should be on NuGet in January. We usually publish on Patch Tuesday, or close to it, so January 10th or thereabouts.

Cool. I subscribed to the NuGet release RSS feed for this package - easy peasy. https://www.nuget.org/packages/System.Security.Cryptography.Xml/atom.xml

[ViktorHofer]

We should do a root cause analysis as to why APICompat (Package Validation) didn't catch this. I would have expected it to flag the removed types compared to last release. cc @ViktorHofer @smasher164

Will take a look. My guess is that the type forwards weren't followed because of references not being available during baseline package validation.