Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Obsolete X509Certificate2.PrivateKey and PublicKey.Key. #54562

Merged
merged 4 commits into from
Jun 28, 2021

Conversation

vcsjones
Copy link
Member

Closes #47977.

@dotnet-issue-labeler
Copy link

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@ghost
Copy link

ghost commented Jun 22, 2021

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks
See info in area-owners.md if you want to be subscribed.

Issue Details

Closes #47977.

Author: vcsjones
Assignees: -
Labels:

area-System.Security, new-api-needs-documentation

Milestone: -

@vcsjones vcsjones added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label Jun 22, 2021
@ghost ghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Jun 22, 2021
@ghost
Copy link

ghost commented Jun 22, 2021

Tagging @dotnet/compat for awareness of the breaking change.

@vcsjones vcsjones marked this pull request as ready for review June 22, 2021 20:41
@vcsjones
Copy link
Member Author

vcsjones commented Jun 22, 2021

Test failures appear unrelated.

Once this is a 👍 from a code review perspective, I think it would be good to run outer loop on this to make sure the S.S.C.Pkcs tests I changed are still passing.

@@ -89,5 +89,8 @@ internal static class Obsoletions

internal const string X509CertificateImmutableMessage = "X509Certificate and X509Certificate2 are immutable. Use the appropriate constructor to create a new certificate.";
internal const string X509CertificateImmutableDiagId = "SYSLIB0026";

internal const string KeyPropertiesMessage = "Key and PrivateKey are obsolete. Use the appropriate method to get the public key, or create a new instance with a different private key.";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The message feels a little... off.

Suggested change
internal const string KeyPropertiesMessage = "Key and PrivateKey are obsolete. Use the appropriate method to get the public key, or create a new instance with a different private key.";
internal const string KeyPropertiesMessage = "PublicKey.Key and X509Certificate2.PrivateKey are obsolete. Use the appropriate method to get the key (such as GetRSAPublicKey or GetRSAPrivateKey), or use the CopyWithPrivateKey method to create a new instance with a private key.";

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use the CopyWithPrivateKey method to create a new instance with a private key.

Well, PublicKey has no such method which is why mine was probably too-vague. I'm starting to wonder if they would be better off as two separate diagnostics.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe I am thinking too hard about this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was looking for precedent of using the same ID with different messages, and don't see that.

Numbers are cheap, splitting them so the message is more actionable makes sense to me. @terrajobst ?

Copy link
Member Author

@vcsjones vcsjones Jun 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I split the diagnostics and think that looks better. I'm happy to revert that last commit and combine them if we come up with how to message both with a single diagnostic message.

Copy link
Member

@terrajobst terrajobst Jun 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way to think about this is like this:

  • Having two messages for the same diagnostic is fine, but I'd be careful that you don't end up with a grab bag for the ID where someone would want to frequently suppress one but not the other. Now, of course there is a trade off. The entire point of having a diagnostic ID is to group multiple different APIs under the same ID. You can always construct a case where someone would want to suppress it in the context of one API but not the other, but for me the imperative word is frequently. People can always suppress specific occurrences by using localized #pragma suppressions, so rare cases where this is needed always have an escape hatch. Having different IDs makes sense when for the entire project people would often want to suppress one ID but not the other. If these cases are exceedingly rare, I'd opt for using the same diagnostic ID.

  • While diagnostic IDs are cheap, try to imagine a VS UI that lists them all and have a user decide which one to turn off/turn. The more granular, the more cognitive load.

  • In other words, neither approach in the extreme is "correct", so it's something that needs domain expertise to dial.

  • And finally, we don't have to get it a 100% correct. Yes, we should avoid changing diagnostic IDs but if we ended up bucketizing two different cases under the same ID, I don't see a reason why, based on customer feedback, we couldn't split it later to make people's life better.

Does this make sense?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@terrajobst that is very insightful, thank you. I'm not sure that feedback pushes me over the edge in to re-combining them. Those APIs feel disparate that two separate codes make some sense.

@bartonjs et al. I am happy to change though if anyone thinks otherwise.

@bartonjs
Copy link
Member

/azp run runtime-libraries-coreclr outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@vcsjones
Copy link
Member Author

None of the build failures look related, but I am having a hard time parsing the results of the Android build error.

@vcsjones
Copy link
Member Author

Merged in main and Android is building, and the previous run's outer loop didn't seem to indicate that any of the changed tests are breaking.

@bartonjs
Copy link
Member

Failures look unrelated. Merging. Thanks, @vcsjones.

@bartonjs bartonjs merged commit af18e93 into dotnet:main Jun 28, 2021
@vcsjones vcsjones deleted the 47977-obsolete-key-props branch June 28, 2021 17:03
thaystg added a commit to thaystg/runtime that referenced this pull request Jun 29, 2021
…bugger2

* origin/main: (78 commits)
  Fix unreached during dump. (dotnet#54861)
  Fix lowering usage of an unset LSRA field. (dotnet#54731)
  Fix setting breakpoints on AVX 256 instructions and other 32 byte immediate instructions (dotnet#54786)
  Add perf_slow yaml (dotnet#54853)
  Faster type load for scenarios made more common by generic math (dotnet#54588)
  Make sure we consider buffer length when marshalling back Unicode ByValTStr fields (dotnet#54695)
  Add YieldProcessor implementation for arm (dotnet#54829)
  Remove ActiveIssue for dotnet#50968 (dotnet#54831)
  Enable System.Text.Json tests for Wasm AOT (dotnet#54833)
  Remove ActiveIssue for dotnet#51723 (dotnet#54830)
  Fix load exception on generic covariant return type (dotnet#54790)
  Obsolete X509Certificate2.PrivateKey and PublicKey.Key. (dotnet#54562)
  First round of converting System.Drawing.Common to COMWrappers (dotnet#54636)
  Fix alloc-dealloc mismatches (dotnet#54701)
  Add one-shot ECB methods
  [Mono] MSBuild Task housekeeping (dotnet#54485)
  Move iOS/tvOS simulator AOT imports in the Mono workload (dotnet#54821)
  Remove unnecessary char[] allocation from Uri.GetRelativeSerializationString (dotnet#54799)
  Reduce overhead of Enumerable.Chunk (dotnet#54782)
  Fix EnumMemberRefs always returning NULL (dotnet#54805)
  ...
@ghost ghost locked as resolved and limited conversation to collaborators Jul 28, 2021
@ericstj ericstj added this to the 6.0.0 milestone Sep 30, 2021
@bartonjs bartonjs removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Sep 30, 2021
@bartonjs bartonjs removed their assignment Sep 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Security breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. new-api-needs-documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider deprecating or annotating a few S.S.C.X509Certificates members
5 participants