Python bump to 3.8.8

[fuzzard]

Description

Bump python and patches to 3.8.8 for tools/depends platforms (Android/Apple).
I guess this may be considered a partial backport of #19246 , but only the package bumps for python, no other changes are backported.

Motivation and Context

There are a couple of security fixes. Release notes with CVE numbers can be seen via the below link

https://www.python.org/downloads/release/python-388/

How Has This Been Tested?

Runtime tested ios/osx

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• [] I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[lrusak]

I don't know if we really have a policy about bumping packages in a release. This is likely fine but worth a discussion about the merits and risks involved. Likely it will be @DaveTBlake's final word. I say this because I would also like to bump libdav1d but am wondering if it's allowed as it may not directly be a "bug fix" which would be the same as this PR.

[fuzzard]

Definitely understand where you are coming from. The one thing i think thats different in the 2 scenario's, this update is specifically to resolve 2 known security CVE's. yes theres other stuff in the 3.8.5-8 changes, but the intent is to fix the security issues.

An option could be to backport the actual fixes to 3.8.5, so if thats the way we want to go i could do that, but i think the more maintainable approach for us is to do the bringup to the official release with the fixes.

Either way, im not fussed. If its not desired, can be closed.

[lrusak]

Either way, im not fussed. If its not desired, can be closed.

Apologies if my previous comment's tone wasn't great. I think this PR is a good thing and I would like to see it included in v19.

I'm not sure if any long term team members can chime in about previous release cycles and what may have been bumped (or not).

[DaveTBlake]

I'm not sure if any long term team members can chime in about previous release cycles and what may have been bumped (or not).

Yes that is what I would like to know. My feeling is we generally don't do it, but possibly just because we are busy moving on, and no technical reason.

This resolves 2 known security CVEs which is reason to do it in v19.1, but are there any downsides to such a bump?

[phunkyfish]

I think bumping the micro version of a dep is ok if fixing security issues.

[wsnipex]

Security fixes must be done. We can't stay old libraries with know security issues forever.
I'd still recommend this goes into master first to get some testing.

[fuzzard]

@Paxxi If you find time to bundle up some 3.8.8 binaries for windows, happy to add to this. No rush though.

[DaveTBlake]

I'd still recommend this goes into master first to get some testing.

Yes, master first and get tested in good time for 19.1

[phunkyfish]

jenkins build this please

[DaveTBlake]

Consensus is we want security updates backported, but not looking like this will make v19.1, since equivalent change has not been merged into master yet. @fuzzard what are your thoughts?

[DaveTBlake]

Bumped to 19.2 as equivalent change has not been merged into master yet.

[thezoggy]

why not just run with python 3.8.11 ?
https://docs.python.org/release/3.8.11/whatsnew/changelog.html#python-3-8-11-final

[fuzzard]

Because 3.8.8 was the most current at the time of this PR