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

[andriipatsula]

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

The issue is blocking: #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.

[garath]

!30725 is merged!

[riarenas]

The changes to pyopenssl and cryptography are being reverted in https://dnceng.visualstudio.com/internal/_git/dotnet-helix-machines/pullrequest/30805.

When we attempt this again, we need to make sure to test the changes in the following OSes by using the FORCE_QUEUE feature:

• redhat7
• sles12
• ubuntu16

which are the older versions, and therefore the most sensitive to package updates.

[riarenas]

I have extended the CG alert related to these changes while we figure how to get these older OSes compliant: https://dev.azure.com/dnceng/internal/_componentGovernance/dotnet-helix-machines/alert/7672729?typeId=15087584

[dougbu]

I'm tempted to try just bumping cryptography to 3.4.8, rather than go all the way to 40.0.2. See latest CG alerts in almost any job w/in build #20230420.06. I'm having trouble finding the earliest version that CG won't warn about however. Thoughts❔

More generally, anyone know whether Python is something we can upgrade on older SLES and RHEL OSes❔

/cc @ilya-bin, @garath, @riarenas

[riarenas]

More generally, anyone know whether Python is something we can upgrade on older SLES and RHEL OSes❔

Not without a lot of pain. SLES 12 especially has always been very sensitive to any python changes.

[garath]

I can double-check but I believe SLES 12 is the reason for the current minimum version. Upgrading was never deemed a reasonable option.

[oleksandr-didyk]

The current image we have for SLES12 contains Python: 3.4.10

The version that CG finds acceptable for cryptography is 39.0.1, which needs python>=3.6

I tried checking out how hard would upgrading the Python version be, so I created a VM out of the produced image in Azure. On that VM, I cannot even install Python's dependencies to compile it due to:

:~> sudo zypper update -y
Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'.
Unexpected exception.
Receive: script died unexpectedly
History:
 - [11-Resource temporarily unavailable]

Please file a bug report about this.
See http://en.opensuse.org/Zypper/Troubleshooting for instructions.

Tried several ways of fixing the issue, no luck so far. I might be missing something or maybe there is a different way to verify if upgrading the version is a complete no-go.

Moreover, I see pyopenssl mentioned in the ticket and the PR, but:

• the CG report does not contain an alert for that package
• that package is not a transitive dependency of cryptography (source)

Is there a reason for why its upgrade is also required @andriipatsula? (since you were the author of the issue)

Additionally, maybe @garath or @riarenas have context into why upgrading Python on SLES 12 was never a reasonable option