runtime: Reference source for System.Security.Cryptography is generated inconsistently between platforms
Somewhat recently, it appears that the GenerateReferenceAssemblySource
is creating changes that are invalid, or at least unwanted.
On macOS or Linux, do:
# Tried on 2737da5
./dotnet.sh build src/libraries/System.Security.Cryptography/src /t:GenerateReferenceAssemblySource
on macOS, this generates a lot of changes that are incorrect. A diff can be seen at https://github.com/dotnet/runtime/compare/main...vcsjones:diff-ssc
Notable things that are incorrect:
- Removing many overrides from
AesCng
, for exampleTryDecryptCbcCore
.AesCng
does override it. - Removing
IDisposable
fromCngKey
.
This behavior only appears in macOS / Linux. On Windows, its results are reasonable, simple ordering or whitespace changes.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 18 (18 by maintainers)
Commits related to this issue
- Run illink before ApiCompat and GenAPI As observed in https://github.com/dotnet/runtime/issues/66634#issuecomment-1068556981, illink currently runs after APICompat. This happens because nuget imports... — committed to dotnet/runtime by ViktorHofer 2 years ago
- Run illink before ApiCompat and GenAPI As observed in https://github.com/dotnet/runtime/issues/66634#issuecomment-1068556981, illink currently runs after APICompat. This happens because nuget imports... — committed to dotnet/runtime by ViktorHofer 2 years ago
- Run illink before ApiCompat (#66706) * Run illink before ApiCompat and GenAPI As observed in https://github.com/dotnet/runtime/issues/66634#issuecomment-1068556981, illink currently runs after APICo... — committed to dotnet/runtime by ViktorHofer 2 years ago
APIcompat’s job has always been to find binary compatibility breaks. Removing an override isn’t binary breaking and it’s actually something that API compat needed to tolerate with a lot of the .NETFramework -> .NET Core refactoring. Today we try to make API compat also check for “ref consistency” by running it backwards but it still ignores some things we would prefer it didn’t. We also have https://github.com/dotnet/arcade/issues/2570 around this behavior in the existing API compat. To better support this scenario the new API compat has a “strict” mode which is meant to catch things like this but I see it still permits an override removal, so I filed an issue to catch that.
I don’t think APICompat was missing anything here. A missing interface would be a break but according to @vcsjones
This was fishy. I tried a local repro and saw the same problem. Here’s what I did to repro (after having a full build):
I could see the diff, so I checked the built assembly (input to genAPI) to see what’s happening. It was also missing the interface! I checked the input to the compiler and found it was correct https://github.com/dotnet/runtime/blob/c3dbdea91835d67cc461b22125e652ad5063d746/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/Cng.NotSupported.cs#L101
I double checked the output of the compiler and it looked like it was missing the interface, which didn’t make sense. So I went to the build log and saw the problem.
If I check the pre-trimmed assembly it had the interface implementation. So the linker was removing it.
So, two problems:
from https://github.com/dotnet/runtime/pull/66706. System.Net.NetworkInformation is impacted as well. https://github.com/dotnet/linker/issues/2238 tracks the linker bug.
I think this just makes it match more similarly to what is already there, not something that is necessarily more “correct”.
For example,
DESCryptoServiceProvider
on Linux / macOS has more overrides than what is present on Windows, soGenerateReferenceAssemblySource
on Linux currently means a diff that results in additional members. I would assume then that both Linux and Windows need the overrides in their implementations.So I believe there are legitimate concerns, in that case or in
RSAOpenSsl
for example, where Windows is missing some overrides.It does feel a bit backwards that GenAPI is running on post-trim and APICompat is on pre-trim.
I can fix the differences but I’m worried we are going to drift again if ApiCompat doesn’t warn us of this. Should I open a separate issue for that?