NSUrlSessionHandler: Adds support for X509 client certificates

[dotMorten]

Addresses #13856

There's a couple of outstanding questions for this PR, so keeping it in draft for now:

1. ~This relies on System.Net.Security.CertificateHelper which is internal. I'm not sure if xamarinios has access to this. If not, should I just copy the file over? It is for instance used here to pick the correct certificate in SocketsHttpHandler and HttpClientHandler.~. Update: Imported a copy.
2. I didn't mark ClientCertificateOptions supported. However, I rely on it being set to Manual (which is the default). I also duplicated the HttpClientHandler behavior for requiring Manual to be set, so I'm sort of using a property we say isn't supported, but Automatic would never be supported.

I also toyed with having a public callback for users to do more native certificate handling, and modeled around the ServerCertificateCustomValidationCallback callback:

	public Func<HttpRequestMessage, NSUrlAuthenticationChallenge, NSUrlCredential?>? ClientCertificateChallengeCallback
	{
		get; set;
	}

	private bool TryInvokeClientCertificateChallengeCallback(HttpRequestMessage request, NSUrlAuthenticationChallenge challenge, [NotNullWhen(true)] out NSUrlCredential? credential)
	{            
		var callback = ClientCertificateChallengeCallback;
		credential = null;
		if (callback is null)
			return false;
		credential = callback(request, challenge);
		return credential != null;
	}

This isn't in the PR, but more than happy to also add that. My thinking was that might enable some scenarios where you can't use the .NET X509 certificates but need to pull native certificate types in

[UtpalJayNadiger]

Hey @benjefferies - currently it's not. Mostly because we haven't heard about this yet from any user. Would love to learn how you see it working though.

[ZIJ]

There is at least one other user who didn't want to use Gitlab's (not Github's) artifact storage for plan files, citing security reasons. I would love to better understand this concern. Currently it seems to me that artifact storage, if used, is assumed to be "high-trust", a bit like the CI environment itself. But I'm likely missing something.

Perhaps @benjefferies could add some context. If not workspace artifacts, what would you use for storage?

[ahuseby]

I think the planfile should be treated the same way the statefile is treated. The statefile may contain sensitive information, and that is why you'd want to limit access to it.

Ways to protect the state file

• Local/committed to git: Limit repo access.
• Remote: Limit resource access (AWS S3, Azure Blob, etc).

The same can be applied for protecting a planfile that potentially contains sensitive information.

Since GCP bucket is already an alternative in Digger, I suggest expanding to AWS S3, Azure Blob, etc.

[chvima]

There is at least one other user who didn't want to use Gitlab's (not Github's) artifact storage for plan files, citing security reasons. I would love to better understand this concern. Currently it seems to me that artifact storage, if used, is assumed to be "high-trust", a bit like the CI environment itself. But I'm likely missing something.

Perhaps @benjefferies could add some context. If not workspace artifacts, what would you use for storage?

I have the same issue on GitHub - Artifacts are available for anyone with Read access to the repository (see https://github.com/orgs/community/discussions/54216 )

I see 2 solutions that work for us:

• allow AWS S3 as mentioned by @ahuseby
• use github artifacts but encrypt the plan file at rest