> So the solution I'm currently in the process of trying is to copy the > version from the oldest supported Python version at Debian package > build time. We'll see how this goes.... > >> Perhaps they have a maintenance script for updating the vendored >> dependencies? You could use that to find out how to reverse the changes, >> or start from a clean slate? > > Unlikely; some of their vendored dependencies date back to Python 2.5!
In that case, I think this is the issue that must be solved first: Ensuring that their code is compatible with the *latest* published version, and vendoring the system version at build time. Not a good solution, since it will still leave the system vulnerable when one of the dependencies gets a security update, but better than shipping a static version that might have numerous issues and will no longer receive any patches. The alternative would be that they take full responsibility for their vendored code, but then it will be much harder to detect when they're affected by a vulnerability.
