This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bmerry
Recipients amacd31, bmerry, christian.heimes, jakirkham, jan-xyz, lukasz.langa, matan1008, methane, ronaldoussoren
Date 2021-07-28.18:09:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1627495764.08.0.133260768929.issue42853@roundup.psfhosted.org>
In-reply-to
Content
> It seems like we could have support for OpenSSL 1.1.1 at that level with a compile time fallback for previous OpenSSL versions that break up the work. Would hope this solution also yields something we can backport more easily

I'd have to look at exactly how the SSL_read API works, but I think once we're in C land and can read into regions of a buffer, reading in 2GB chunks is unlikely to cause a performance hit (unlike the original bpo-36050, where Python had to read a bunch of separate buffers then join them together). So trying to have 3.9 support both SSL_read_ex AND have a fallback sounds like it's adding complexity and risking inconsistency if the fallback doesn't perfectly mimic the SSL_read_ex path, for very little gain.

If no-one else steps up sooner I can probably work on a patch, but before sinking time into it I'd like to hear if there is agreement that this is a reasonable approach and ideally have a volunteer to review it (hopefully someone who is familiar with OpenSSL, since I've only briefly dealt with it years ago and crypto isn't somewhere you want to make mistakes).
History
Date User Action Args
2021-07-28 18:09:24bmerrysetrecipients: + bmerry, ronaldoussoren, christian.heimes, methane, lukasz.langa, jakirkham, matan1008, amacd31, jan-xyz
2021-07-28 18:09:24bmerrysetmessageid: <1627495764.08.0.133260768929.issue42853@roundup.psfhosted.org>
2021-07-28 18:09:24bmerrylinkissue42853 messages
2021-07-28 18:09:23bmerrycreate