Replacing Yubico.DotnetPolyFills with PolySharp. Bumping LanguageVersion to C#12.

[DennisDyallo]

Description

This update removes the need for the Yubico.DotnetPolyfills-project. This project was adding a couple of methods, such as CryptographicOperations.ZeroMemory and the Index operator. Now, since adding Polysharp, this is no longer needed as Polysharp generates polyfills for newer C# language features and APIs at compile-time. This also allows us to use C# language version 12 instead of 7.3.

It's true that bringing in a dependency into any library should not be taken in lightly. This suggestion has been with the team for some time, and while we haven't committed to it yet, we want to explore the possibility of making such a change. We do believe measures can be taken to ensure stability and expected behavior. Rest assured, although the third party dependency in question appears to be well regarded, useful and stable, it won't be added without going through a due dilligence process.

To you and anyone else reading this, please feel free to add your comments or any alternatives to move the SDK forward in this regard.

Fixes: YESDK1316

Type of change

How has this been tested?

Unit tests pass and builds pass.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have run dotnet format to format my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[github-actions]

Test Results: Windows

    2 files      2 suites   5s ⏱️
3 700 tests 3 700 ✅ 0 💤 0 ❌
3 702 runs  3 702 ✅ 0 💤 0 ❌

Results for commit 85a888e.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results: Ubuntu

    2 files      2 suites   9s ⏱️
3 692 tests 3 692 ✅ 0 💤 0 ❌
3 694 runs  3 694 ✅ 0 💤 0 ❌

Results for commit 85a888e.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results: MacOS

    2 files      2 suites   3s ⏱️
3 692 tests 3 692 ✅ 0 💤 0 ❌
3 694 runs  3 694 ✅ 0 💤 0 ❌

Results for commit 85a888e.

♻️ This comment has been updated with latest results.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
Yubico.Core	42%	32%	4278	➖
Yubico.YubiKey	50%	47%	19122	➖
Summary	48% (32015 / 66351)	44% (8160 / 18540)	23400	➖

Minimum allowed line rate is 40%

[iamcarbon]

This introduces an untrusted third party dependency into a security critical library. It would be better to selectively port the individual Polyfills into core, then introduce a new dependency (and extend the chain of trust).

[DennisDyallo]

This introduces an untrusted third party dependency into a security critical library. It would be better to selectively port the individual Polyfills into core, then introduce a new dependency (and extend the chain of trust).

Hi @iamcarbon and thanks for your raised concern. It's true that bringing in a dependency into any library should not be taken in lightly. This suggestion has been with the team for some time, and while we haven't committed to it yet, we want to explore the possibility of making such a change. We do believe measures can be taken to ensure stability and expected behavior. Rest assured, although the third party dependency in question appears to be well regarded, useful and stable, it won't be added without going through a due dilligence process.

To you and anyone else reading this, please feel free to add your comments or any alternatives to move the SDK forward in this regard.

@dainnilsson @GregDomzalski FYI