On Thu, 2020-09-10 at 13:37 +0300, Matti Picus wrote:
On 9/10/20 12:40 PM, Michał Górny wrote:
I've filed two MRs for a start: https://foss.heptapod.net/pypy/pypy/-/merge_requests/752 https://foss.heptapod.net/pypy/pypy/-/merge_requests/753
Could you please let me know if that approach is ok? If so, I'll tackle the remaining vulnerabilities (around 6 patches FWICS).
Thanks.
Could you add comments in each patched chunk of each PR that will allow us to track how the code diverged? Something like "added manually to resolve bpo xxx".
I don't see a problem with doing that.
I am concerned this will make an eventual update to the stdlib difficult. MR753 is quite invasive. Are all the other patches against the same single file? Maybe a different strategy would be to adopt the file and tests as-is from the HEAD of the CPython branch, as long as no user-facing APIs change.
I suppose I can try doing that. I presumed you'll want to keep the changes to bare minimum possible but it might turn out not much different once I iterate over all the CVEs.
It would be nice to make similar PRs against default (python2.7) in lib-python/2.7 on that branch.
The primary problem with that is that CPython 2.7 is abandoned and contrary to all the big talk about random people willing to maintain it post-EOL, I am yet to see anyone taking its security seriously. So far I and the Fedora maintainer were able to independently backport one vulnerability that clearly applied (the tarfile one) but we weren't able to get a clear match of any other Python 3.x fixes to 2.7 codebase. Well, until today when thanks to you I've noticed that http.request code has a vulnerable match in httplib. But this all is lots of work, and I'm really supposed to be doing something else right now. I'm trying my best but I'm not sure if I can manage to fix several months of negligence in two days. -- Best regards, Michał Górny