Update gitpython (security)

[arm4b]

Taking one dependency at a time into a separated PRs from #6062 to see what could be merged safely ASAP.

This updates gitpython==3.1.37 (security fixed) under py3.8 and gitpython==3.1.18 (latest installable, but vulnerable) under py3.6

Checking the build artifacts for shipped gitpython versions:

• U18 (py3.6) - gitpython==3.1.18 (build)
• U20 (py3.8) - gitpython==3.1.37 (build)
• EL7 (py3.6) - gitpython==3.1.18 (build)
• EL8 (py3.8) - gitpython==3.1.37 (build)

We should drop the Python 3.6 support after the 3.8.1 patch release and pin githpython explicitly.

[amanda11]

I'm approving, but I'm just wondering about the pants lock files as st2.lock and bandit.lock refer to version 3.1.18.

[arm4b]

@amanda11 Experimented a bit and found that in the pants settings we rely on interval between python3.6 (inclusive) until python3.10:

st2/pants.toml

Lines 105 to 112 in 32a243a

	[python]
	# resolver_version is always "pip-2020-resolver". legacy is not supported.
	enable_resolves = true
	default_resolve = "st2"
	interpreter_constraints = [
	# python_distributions needs a single constraint (vs one line per python version).
	# officially, we exclude 3.7 support, but that adds unnecessary complexity: "CPython>=3.6,!=3.7.*,<3.10",
	"CPython>=3.6,<3.10",

According to that, gitpython==3.1.18 for py3.6 is the correct version for the pants lock as it satisfies all the python version requirements. I tried and it wasn't possible to install dynamically specific package version depending on the python_version marker.

Checking further, if we remove py3.6 from the pants settings, then it would allow using a higher version of gitpython in the lockfile. Not sure if we want to drop py3.6 from pants now or in the v3.9.0 per #6064

[arm4b]

Update: Yeah, removing py3.6 from pants will try to regenerate all the requirements/lockfile - it probably fits a dedicated PR in the larger scope of v3.9.0.