Import X509 certificate and collections from PEM.

[vcsjones]

Fixes #31944

This does not have unit tests that exercise the *File import methods. While I'd like those tested, I'm not sure of the best way to do it. Write the file out to a temp location? Or should I add a bunch of files to runtime-assets package and open a PR there? Is there documentation about validating that it works locally?

[Dotnet-GitSync-Bot]

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]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[bartonjs]

While I'd like those tested, I'm not sure of the best way to do it. Write the file out to a temp location? Or should I add a bunch of files to runtime-assets package and open a PR there?

Start with the temp file route. After everything is happy and stable we can add some things to the testdata package for the verisimilitude of loading a file that existed on disk before the process started.

[vcsjones]

we can add some things to the testdata package

Is there any practical benefit of doing this now if we can write temp files? My recollection from .NET Core 1.0 on Jenkins was that writing to disk was not a good idea because test interruptions would leave data behind and the environment was not ephemeral. If that's no longer true then I don't see much of a value add from adding files to the test data package.

[bartonjs]

we can add some things to the testdata package

Is there any practical benefit of doing this now if we can write temp files?

Not really. Mostly aesthetic or a "feel good" scenario completion feeling. I think the current model is fine, though.