Summary

As part of DRIVERS-3564, in https://github.com/mongodb-labs/drivers-evergreen-tools/pull/829, we added a set of integration tests and a fallback option in our bootstrapping script, ensure_uv. The tests and fallback cover the following case: a KMS VM provisioned before PYTHON-5985 (4c63815), which has python3-venv but no pip, and where Debian refuses ensurepip outside a venv.

The failure mode was that a remote host would check out master rather than the pinned revision, pairing provisioning from an old pin with current bootstrapping code.

Later, as part of DRIVERS-3564 (5be304d), we prevented this disconnect from recurring by shipping a copy of the local git archive to use on the remote host.

Some release branches still pin drivers-evergreen-tools revisions older than 4c63815, and so predate both fixes.

Motivation

Who is the affected end user?

Driver teams maintaining release branches that run the azurekms or gcpkms tests, and drivers-evergreen-tools maintainers carrying the fallback.

How does this affect the end user?

Nothing is broken. This is maintenance: there is a code path in ensure_uv that no current provisioning reaches, plus a nightly kms-legacy build variant that provisions two extra VMs a day purely to keep that path working.

How likely is it that this problem or use case will occur?

Main path for the affected branches. Any KMS test run from a pin older than 4c63815 ends up using the fallback.

If the problem does occur, what are the consequences and how severe are they?

Minor. The cost is the maintenance burden and two VM provisions a night, not a failure.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No. Closing it removes a fallback in ensure_uv along with the test infrastructure that covers it.

Acceptance Criteria

• Every release or default branch that still runs the azurekms or gcpkms tests pins drivers-evergreen-tools at 4c63815 or later, or is confirmed to no longer run them.
• The four DRIVERS-XXXX markers in drivers-evergreen-tools are resolved by deleting the venv fallback in ensure-uv.sh, the kms-legacy variant in config.yml, and the two frozen scripts under csfle/*/remote-scripts/legacy/.

I ran a search across mongodb and mongodb-labs orgs and found these potential targets.

Pins older than 4c63815, as of 2026-08-23:

The master branches of mongo-ruby-driver, node-mongodb-native and mongo-go-driver are already current.