Backport fix for bpo-38804

[wshanks]

Recently, a CVE was published for this project related to a CVE previously patched in Python. I am not sure if this project is still maintained any more but it is still listed as a dependency by some other popular projects, so it would be good to patch.

The regex http.cookiejar.LOOSE_HTTP_DATE_RE was vulnerable to regular expression denial of service (REDoS). The regex contained multiple overlapping \s* capture groups. A long sequence of spaces can trigger bad performance.

See python/cpython#17157 and https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages/

[mgorny]

Given the huge pile of patches we're applying in Gentoo to make it work with Python 3.10, I dare say it's as dead as it can get. However, thank you for making a PR nevertheless, as it makes it easier to patch the CVE on our end (and other distros will probably appreciate that too).

I just hope that GitHub's fancy bots will now start flagging the future library as vulnerable and people will actually care to stop using it. OpenStack is particularly in love with it, and it's true horror.

If you wish to help even some, some help in reporting the use of unmaintained library and convincing people to stop using it would be really appreciated. A lot of distro maintainers have been burned out doing exactly this, i.e. fighting the "it is my project, I can do whatever I like, however bad it is for my users" attitude.

[wshanks]

Thanks @mgorny! I saw there was little activity in the commit log and that there were approved PR's sitting unmerged, but I hadn't realized that the package was actually not working in recent Python versions without patching.

Some good news for you is that a bot flagging CVE's in my subdependencies (though not GitHub's bot) was what led me here.

I will try to encourage future be dropped from packages I depend on. I thought the CVE should at least be acknowledged somewhere on the repo which might help with that. Also, your comment here should help.

Luckily for me, my dependencies seem to be only referencing builtins and just need to drop future from their dependencies without any code changes.

[sfdye]

Thanks for the fix! Now I just need to figure out how to create a release (and upload to pypi) for this project, as the last time I did was a few years ago..

[sfdye]

0.18.3 released!
https://pypi.org/project/future/0.18.3/

[wshanks]

Nice, @sfdye. I feel like there might not be much motivation for maintaining this package going forward, since most of the community has migrated to Python 3 by now. From what @mgorny said, there are issues with using future on recent versions of Python 3. I don't know the details of those, but I imagine there are a lot of Python packages that just left future in their dependencies even though they do not use it in Python 3 (based on all the references to this PR above). I wonder if something could be done from the future side to encourage projects to move on, like a notice in the readme about the current level maintenace (unless someone wants to review and merge PR's about compatibility with 3.10 and 3.11 but I don't see the motivation).