-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenSSL 1.1.1: use SSL_write_ex() and SSL_read_ex() #87020
Comments
SSL_read() and SSL_write() are limited to int. The new SSL_write_ex() and SSL_read_ex() APIs support size_t just like read(2) and recv(2). Also see bpo-42853. int SSL_write_ex(SSL *s, const void *buf, size_t num, size_t *written);
int SSL_read_ex(SSL *ssl, void *buf, size_t num, size_t *readbytes); Both functions return 1 for success or 0 for failure. |
As of version 3.3.1, LibreSSL does not have SSL_write_ex() and SSL_read_ex(). The read and write functions are limited to int. |
3.10 branch now requires OpenSSL 1.1.1. This should be easy to implement. |
Ethan, what's your platform and OpenSSL version? |
False alarm, sorry. Still getting used to merging, rebasing, etc. Current tests run fine. |
I am still seeing failures to read responses over 2 GB in Python 3.10b1. I'm working on a reproducer, but I'm getting the same "OverflowError: signed integer is greater than maximum" that I get in 3.9. |
Christian mentioned on Twitter that this is probably due to a missing argument clinic change from "int" to "Py_ssize_t". I can confirm that fixing that and rerunning argument clinic makes things start to work. I don't have the ability to reopen this bug (I think), can someone reopen it please? |
I will push a fix today |
Two reverts were opened after this issue was resolved:
I could not find any discussion regarding these reverts, so it is not immediately obvious if they are still needed. @pablogsal, your review was requested for both of these reverts; do you remember the discussion? |
I remember my commit but unfortunately I don't remember the discussion for the reverts :( |
Well, given that the reverts were not applied for 1,5 years, perhaps we could close those PRs. It would seem to me that there would exist an issue for this if these were release blockers or if they represented critical bugs. |
I closed the revert PRs. We can open them later if needed. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: