Resolve the Component Governance issue in the dotnet-helix-machines repository

• This issue is blocking
• This issue is causing unreasonable pain

The issue is blocking: https://github.com/dotnet/arcade/issues/13166 and any PR to the dotnet-helix-machines repository.

Component Governance Component Detection: https://dev.azure.com/dnceng/internal/_build/results?buildId=2160248&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=833edf1b-3669-5dbb-11e6-ee7d22230825&l=1967

Release Note Category

• Feature changes/additions
• Bug fixes
• Internal Infrastructure Improvements

Release Note Description

Increased the installed Python cryptography and pyopenssl versions on most build and test agents to 41.0.1 and 23.2.0, respectively. Due to restrictions in our infrastructure, this change will be reflected on https://helix.dot.net as >=39.0.1 and >=23.0.0 rather than the exact versions installed.

The cryptography and pyopensll versions on all SLES 12 and Ubuntu 16.04 are significantly older due to platform issues we have not yet resolved. See dotnet/dnceng#293 and dotnet/dnceng#294 for details.

[dougbu]

After much experimentations and unblocking many problems (e.g., w/ FORCE_QUEUEs), this is finally waiting for rollout. dotnet/dnceng#293 and dotnet/dnceng#294 track work on the couple of images that still have an old cryptography version.

[oleksandr-didyk]

What are the available options to solve this problem then @oleksandr-didyk Oleksandr Didyk FTE ?

Initially we could:

• upgrade cryptography on the affected machine - as for reasons mentioned here I would argue that this option is too costly. From comments in this issue + internal comms it seems @dougbu is doing some additional work in this path and can verify / argue against this conclusion
• request and exception for the this specific package - as mentioned in internal comms and in-person meetings this is something that is possible and has occurred in the past (not sure if the past instances related to Python packages or not). A potential issue with this solution is that some other alert can pop-up in the future relating in some shape or form to cryptography and we might need to silence it as well
• drop support for the OS in the first place - no OS means no issues. However, as mentioned in discussions, this would receive great pushback from the product teams since .NET 6 and .NET 7 should support the OS + the original issue is not with the product itself, rather with the infra used for building / testing. Dropping support for an OS just because of that doesn’t look plausible

As such from my perspective it looks like seeking an exception for the alert is the way to go.