-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
tests: support implicit SSL mail protocols #10077
Conversation
From the current CI test results:
|
3fa4c5e
to
3d24fe2
Compare
Why? rustls is supposed to generally work fine.
Hm, yes it is supposed to first verify that the non-stunnel server works before it starts stunnel. See |
It has 12 disabled tests that are supposed to work with. That's why I asked.
I've reused the ftps code for the mail protocols (I even renamed |
Right, but we use TLS in many more tests than just those. These are just tests that for some reason fail with rustls. It is still expected to work just like the other backends unless there's some anomaly. |
There are test failures now with NSS and rustls. Are they permafails or flaky? |
They seem to be non-flaky. |
Maybe make it a "draft" PR for the time being then to make it more visible to observers? |
Since NSS is already deprecated and scheduled for deletion in August, it feels like a boring job to try to work on a bugfix now for an issue that probably has existed for a long time already and obviously has not disturbed any users enough to report it to us. It feels attractive to just mark this single test disabled for NSS builds.
rustls also already has a range of tests disabled so it wouldn't be too terrible to add a few more to that list. This backend is stilled marked experimental for this reason. It generally takes someone with a little insight into rustls and its API to work on these issues. |
Thanks for your comment. In the meantime I've found the problem with NSS: the When some TLS data is buffered by the backend, there's therefore no chance to see it and wake the handle. The problem is likely to occur with all backends not specifically implementing I've managed to make it work with NSS in two ways:
rustls does implement I then consider this problem as the first one being detected by this PR and already existing before it. Do you want a separate issue report for it ? I think it should be fixed (for all backends) before we commit the current PR to avoid "parasitic" reports in the CI tests. |
I think at least a separate PR would make sense, yes! |
I can produce one for NSS only. However the problem should probably be handled more generally, either for each backend or by supporting (blocking?) data reads from backends that do not implement The rustls backend code is out of my skill. |
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077
Should be OK now. |
New tests 987, 988 and 989, disabled for rustls (hanging).
New tests 987, 988 and 989, disabled for rustls (hanging). Closes #10077
Thanks! and sorry for taking so long |
Never mind and thanks for pulling. |
NSS currently uses the default Curl_none_data_pending() method which always returns false, causing TLS buffered input data to be missed. The current commit implements the nss_data_pending() method that properly monitors the presence of available TLS data. Ref:curl#10077 Closes curl#10225
New tests 987, 988 and 989, disabled for rustls (hanging). Closes curl#10077
And as bonus, use a hash table in runtests.pl for server ports and introduce 3 new tests for cases exposed in #10053.