-
-
Notifications
You must be signed in to change notification settings - Fork 719
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
Read smaller frames to workaround OpenSSL bug #5115
Conversation
distributed/comm/tcp.py
Outdated
@@ -35,6 +38,7 @@ | |||
|
|||
|
|||
MAX_BUFFER_SIZE = MEMORY_LIMIT / 2 | |||
C_MAX_INT = 256 ** ctypes.sizeof(ctypes.c_int) // 2 - 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT the limit to what OpenSSL can handle is based on the maximum value of int
in C (as used by num
bytes in this call). This is implementation specific. So am using ctypes
to figure that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to back this up, the following C program (on my machine) gives this result
#include <stdio.h>
#include <limits.h>
int main() {
printf("%lu\n", INT_MAX);
return 0;
}
2147483647
Using this Python code (on my machine), I get the same result.
import ctypes
print(256 ** ctypes.sizeof(ctypes.c_int) // 2 - 1)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed the variable to C_INT_MAX
. Otherwise the code is the same
54a734b
to
14247d5
Compare
420bf97
to
ca30c78
Compare
As older versions of OpenSSL (in particular 1.0.2) have limitations on the size of buffers they can work with, take small views into our larger buffer and read those in instead. This should keep the buffer sizes more manageable for OpenSSL.
Looks like the one CI test failure is a known flaky test ( #4957 ) |
cc @fjetter |
@jakirkham if you're confident that this is a good fix I'm more than happy to trust you on it. Please merge at will if so. |
Doing the same thing for the |
Supercedes dask#5134 Copying over the summary of that PR Works around the OpenSSL 1.0.2 bug demonstrated in issue ( dask#4538 ), except unlike PR ( dask#5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL
Supercedes #5134 Copying over the summary of that PR Works around the OpenSSL 1.0.2 bug demonstrated in issue ( #4538 ), except unlike PR ( #5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL
As older versions of OpenSSL (in particular 1.0.2) have limitations on the size of buffers they can work with, take small views into our larger buffer and read those in instead. This should keep the buffer sizes more manageable for OpenSSL.
black distributed
/flake8 distributed
/isort distributed
Closes #4538