Add API to enable comparision of corefx's OpenSSL with a 3rd party P/Invoke #32900
Conversation
| int minor = (int)((versionNumber >> 20) & 0xFF); | ||
| int fix = (int)((versionNumber >> 12) & 0xFF); | ||
|
|
||
| s_opensslVersion = new Version(major, minor, fix); |
There was a problem hiding this comment.
Where is this used? I'm just surprised to see us parsing it like this, given that we explicitly opted to expose a long due to it being opaque data. Is this just for test code? And if so, should this OpenSslVersion property be moved into a test assembly somewhere?
There was a problem hiding this comment.
Is this just for test code?
Yeah.
And if so, should this OpenSslVersion property be moved into a test assembly somewhere?
What a remarkably reasonable question that means I have more work to do. Okie dokie 😄.
|
@dotnet-bot Test Linux arm64 Release Build please (System.Net.Internals.SocketExceptionFactory+ExtendedSocketException : Resource temporarily unavailable during NameResolution tests) |
|
@dotnet-bot Test Linux arm64 Release Build please |
…Invoke (dotnet/corefx#32900) * Add OpenSslVersionNumber * Fix native compilation * Seed some API doc comments * Add a test * Move (test) PlatformDetection's OpenSslVersion into PlatformDetection. Commit migrated from dotnet/corefx@05d119e
This adds SafeEvpPKeyHandle.OpenSslVersion.
3rd party code which is doing a P/Invoke into OpenSSL (direct or via their own shim) and using RSAOpenSsl..ctor(SafeEvpPKeyHandle) (or DSAOpenSsl or ECDsaOpenSsl) is encouraged to invoke the appropriate version function for their library (
SSLeay()orOpenSSL_version_number()) and compare that against the value ofSafeEvpPKeyHandle.OpenSslVersion.As a structural change, this also changes the shim method from a 32-bit to a 64-bit answer, to ensure that we don't truncate in the future if 64-bit OpenSSL changes versioning schemes to exceed a 32-bit value (the native API returns a *NIX C long).
Fixes #32718.