Update dotnet-install verification step

[nrcventura]

Many of our dockerfiles in the /dockerfile folder have a step where we install dotnet by downloading the install-dotnet shell script, and then comparing its SHA to a known good SHA. These steps are done primarily for change notification tracking. We should document why we have these steps in the dockerfile along with the process for updating the sha.

1. Review the output of the failing run to grab updated sha from the output.
2. Update the dockerfiles to use the new SHA

In addition to this, we can add a verification step to these dockerfiles that validates the signature of the script.

We can add the public signing keys to our repo, and follow the steps in https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script#signature-validation-of-dotnet-installsh to validate the signature of the script. We just need to skip the step of downloading the signature verification key, because it will already be in the repo.

Then when the signature verification step fails, we can see if it was due to a problem, or the key expiring. If there's a problem, then we can't trust the script and should not run it. If the key expired we need to get the updated key.

When we need to update the key we should require someone to take the following steps. These steps should also be documented.

1. Download the install-dotnet script and key
2. Review the contents of that script to verify that it is safe to use.
3. Verify the signature of the script using the downloaded key
4. Update our repo to use the new key

[RassK]

I think it was never a security change but "a notification" that tracks dependency changes due to some requirement that all dependencies must be versioned (so SHA is the script's version).

So I guess a public key validation can be a next layer.

[nrcventura]

I think it was never a security change but "a notification" that tracks dependency changes due to some requirement that all dependencies must be versioned (so SHA is the script's version).

So I guess a public key validation can be a next layer.

I updated the description of the issue to reflect this information, so now it has 2 parts to it.

1. Document why we have the sha check, and what to do when it changes.
2. Optionally add the signature verification step and corresponding update documentation.