Sign almost all the things

[lewing]

The goal here is to sign everything we can. After much testing the main insight is that 3PartyScriptsSHA2 works for the script files and some of the previously complicated files no longer exist. There are still a couple of problems:

1. It is actively wrong to sign the emscripten library js since emscripten uses text transforms to combine it all together so we should test what ends up in the output before merging this. Because of this it's likely we'll need to not sign js still. I don't see a workable way to sign some tooling js and not the library js (perhaps we could sign some files before they are packaged?)
2. The arcade tooling shouldn't attempt to sign zero length files, it will fail and retry until timeout. There are valid reasons for thing like zero length __init__.py files to exist and there is no way to deal with them at the moment.
3. Because of something unknown that is causing the windows embuilder steps to take unreasonably long (unrelated to this pr) those legs appear to be even more likely to timeout with the additional signing.

[lewing]

latest official build run https://dev.azure.com/dnceng/internal/_build/results?buildId=2515475&view=results

[joeloff]

LGTM. For the 0-byte files, should we add something in Arcade to always ignore 0 byte files or allow repos to set a flag that says don't sign 0 byte files because otherwise we'll need to continue adding exclusions like the RemoveDir logic in the emsdk.proj

[mmitche]

What kind of time does this add to the build?

[mmitche]

• The arcade tooling shouldn't attempt to sign zero length files, it will fail and retry until timeout. There are valid reasons for thing like zero length __init__.py files to exist and there is no way to deal with them at the moment.

dotnet/arcade#15001

[mmitche]

• It is actively wrong to sign the emscripten library js since emscripten uses text transforms to combine it all together so we should test what ends up in the output before merging this. It's likely well need to not sign js still. I don't see a workable way to sign some tooling js and not the library js (perhaps we could sign some files before they are packaged?)

Can you describe a pattern that you would write in your Sign.props that we could implement to handle these cases? Generally the sign infra has always focused on file name and file extensions to calculate target sig. In some cases it takes into account public key tokens.

[joeloff]

What happened to the .vbs entry?

[lewing]

There are no vbs files anymore

[lewing]

3. Because of something unknown that is causing the windows embuilder steps to take unreasonably long (unrelated to this pr) those legs appear to be even more likely to timeout with the additional signing.

Interestingly this slowdown appears to only happen on the official build.