PYTHON-5931 PYTHON-5935 Fix auth-aws-ecs and kms test failures

[blink1073]

PYTHON-5931 / PYTHON-5935

Changes in this PR

Fixes the auth-aws-ecs and kms (Azure/GCP) Evergreen tests, which were both failing on their remote/ephemeral test hosts.

Test Plan

Verified with a passing Evergreen patch covering all affected tasks (test-auth-aws-ecs, test-gcpkms, test-azurekms, and the auth_oidc remote variants): https://spruce.corp.mongodb.com/patch/6a518b361480fd00075f1a1d

Checklist

Checklist for Author

• Did you update the changelog (if necessary)?
• Is there test coverage?
• Is any followup work tracked in a JIRA ticket? If so, add link(s).

Checklist for Reviewer

• Does the title of the PR reference a JIRA Ticket?
• Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
• Is all relevant documentation (README or docstring) updated?

[Copilot]

Pull request overview

Updates the Evergreen ECS-host test setup for MONGODB-AWS authentication by ensuring the test container has the missing git dependency required for the auth-aws-ecs test to run successfully.

Changes:

• Install git alongside build-essential in the ECS test bootstrap script.

[blink1073]

This is the wrong approach - we need to pass UV_NO_LOCK to the ecs and kms environments, that's what we were missing from #2881

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[semgrep-code-mongodb]

Semgrep identified an issue in your code:

[tool.uv] has no exclude-newer setting, so uv may immediately install freshly published dependency versions. That lets a malicious new release of packages like gevent, simplejson, or ruff reach developer or CI environments right away.

More details about this

[tool.uv] sets default-groups = ["dev"] but does not set exclude-newer, so uv can resolve package versions published moments earlier during installs or syncs. In this project, a developer or CI job running uv sync could pull a just-uploaded release for dependencies such as gevent, coverage, simplejson, typing_extensions, or even tooling like ruff and mypy.

A plausible attack looks like this:

1. An attacker compromises a package maintainer account or publishes a malicious dependency version that satisfies one of these version ranges, for example simplejson>=3.17.0 or gevent>=21.12.
2. They upload the bad release to the package index and wait for this repository to run uv sync or another uv resolution step using this [tool.uv] configuration.
3. Because [tool.uv] has no exclude-newer, uv is allowed to select that brand-new version immediately.
4. The malicious package then runs in the developer or CI environment during install or import, letting the attacker steal tokens, read source code, or alter test/build output.

Without a cooldown in this exact uv config block, the project has no buffer period to avoid freshly published dependency versions that may be malicious or unstable.

To resolve this comment:

✨ Commit fix suggestion

1. Add a dependency cooldown to the [tool.uv] section by inserting exclude-newer = "7 days" alongside the existing settings.
2. Keep the existing default-groups = ["dev"] entry as-is, so the section looks like [tool.uv] ... default-groups = ["dev"] ... exclude-newer = "7 days".
3. Use at least 7 days for this value; do not use a smaller number or a different format. This makes uv avoid resolving packages published too recently.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by uv-missing-dependency-cooldown.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}