[release/6.0 Cleanup remaining SSP references

[dougbu]

• follow up to e58a6c2
• remove references to System.Security.Permissions or its closure
  • only mentions are in eng/PackageOverrides.txt and eng/PlatformManifest.txt
  • those files will remain unused until we update them in the run-up to 6.0.1
• still indirectly pick up package refs for SSP and its closure but that does not impact targeting pack content

nit: Only need to exclude System.Net.Quic and System.Security.Cryptography.Pkcs from @(_AvailableRuntimeRefAssemblies)

• assemblies are not in @(ReferencePathWithRefAssemblies), just the transport package

[wtgodbe]

those files will remain unused until we update them in the run-up to 6.0.1

Can you file an issue for this?

[wtgodbe]

Again LGTM assuming the outputs look good

[ViktorHofer]

and System.Security.Cryptography.Pkcs from @(_AvailableRuntimeRefAssemblies)

How is Pkcs getting into the closure? Is it part of the transport pack?

[dougbu]

Can you file an issue for this?

No need. The 6.0.1 build won't work w/o the updated files 😀 This is part of what we should document for major version branding updates too.

How is Pkcs getting into the closure? Is it part of the transport pack?

We build the entire closure now that 0b0bed3 is in.

My point was different in any case: @(_AvailableRuntimeRefAssemblies) lists the files from the internal transport package. We need the ref/ assemblies for QUIC and PKCS to build our stuff but they must not land in our targeting package.

[dougbu]

Assert.Empty() Failure
Collection: ["System.Net.Quic", "System.Security.Cryptography.Pkcs"]

Need to double-check my @(_AspNetCoreAppPackageOverrides) exclusions and see where these assemblies are coming from. Likely need to undo a part of this change.

[ericstj]

Suggested change

	@(ReferencePathWithRefAssemblies->WithMetadataValue('NuGetPackageId', 'Microsoft.NETCore.App.Ref'))" />
	@(ReferencePathWithRefAssemblies->WithMetadataValue('Filename', 'System.Net.Quic'));
	@(ReferencePathWithRefAssemblies->WithMetadataValue('Filename', 'System.Security.Cryptography.Pkcs'));
	@(ReferencePathWithRefAssemblies->WithMetadataValue('NuGetPackageId', 'Microsoft.NETCore.App.Ref'))" />

[dougbu]

A reasonable suggestion given that's what we did before.

But, the intent can be made more obvious by excluding all of $(RuntimeTransportReferenceDirectory)*.dll instead of the @(_ReferencedRuntimeRefAssemblies) subset. The double-exclusion just looks wrong and that's why I wanted to remove it. Will try my approach and fall back to your suggestion if that fails.

[ericstj]

I see, I wasn't certain what any of this does, just noticed a place where I thought it might have been accidental.

[ericstj]

How is Pkcs getting into the closure? Is it part of the transport pack?

It's a dependency of Crypto.Xml which gets referenced by DataProtection. It's not exposed by any surface area in ASP.NET nor Crypto.Xml which is why it has been be excluded, but if ASP.NET wanted to implement the intent of your changes here dotnet/runtime#53892, @ViktorHofer, they could decide to just expose it. I'm not sure if its the best time to make that change, but something to consider perhaps for 7.0 if it simplifies things. We'd want to get @bartonjs's blessing that exposing Pkcs would be no worse than Crypto.Xml.

[bartonjs]

We'd want to get @bartonjs's blessing that exposing Pkcs would be no worse than Crypto.Xml.

Pkcs we like. We may not have the best of APIs in there, but it's based on tech we're happy with. It's also a library that has seen new types and new functionality added to it since the start of .NET Core, unlike Crypto.Xml.

So, definitely "no worse than" :)

[dougbu]

We'd want to get @bartonjs's blessing that exposing Pkcs would be no worse than Crypto.Xml.

Pkcs we like. We may not have the best of APIs in there, but it's based on tech we're happy with. It's also a library that has seen new types and new functionality added to it since the start of .NET Core, unlike Crypto.Xml.

So, definitely "no worse than" :)

For 6.0, we ship both Crypto.Pkcs and Crypto.Xml in our shared frameworks but only Crypto.Xml in our targeting packs. Only the native aspnetcorev2_inprocess module (on Windows) and System.Diagnostics.EventLog.Messages (which isn't needed in the targeting pack) are treated similarly to Crypto.Pkcs. So, Crypto.Pkcs is the one "obviously unaligned" assembly here.

We can align things by removing the Crypto.Pkcs exclusion. But, is this worthwhile for our 7.0.x customers if we aren't using Crypto.Pkcs types in our public API❔ If yes, we should first get Crypto.Pkcs into the Microsoft.Internal.Runtime.AspNetCore.Transport package.