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
Tlsfuzzer external tests #17340
Tlsfuzzer external tests #17340
Conversation
Now I switched off the failing tests. This PR adds some tests using the TLSFuzzer test framework. Currently it's basically an infrastructure PR, but it will be extended to run more tests. TLSFuzzer is more flexible than s_client/s_server utilities. It is extensively used in Red Hat TLS testing, and there were (and will be) a lot of issues found by it. Could you please give a feedback whether we are interested in this test suite? |
I think it would be good to have this. We have typically used the external tests as regression tests and only infrequently do we update the submodules and bring the external tests up to date. The more coverage we can get for regression testing the better IMO. |
Here are the examples of using TLSFuzzer with other libraries: gnutls: https://gitlab.com/dueno/gnutls/-/tree/master/tests/suite/tls-fuzzer |
check_update failure seems irrelevant. Ping @levitte (?) |
Ready for review. Ping @t8m @mattcaswell @tomato42 After this PR is merged, I will significantly extend the set of the tests. |
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.
For first, example tests, I'd say use of test-tls13-conversation.py
and test-conversation.py
would be better, as they are a). simple, and b). pass.
Current state of the tests is agreed with @tomato42. If they pass, the PR should be ready to merge. It could (and will) be extended later with other test cases. |
IMO this does not belong to 3.0 branch. As this is a completely new test case. |
@t8m I'd suggest add this to master and decide if it should be added to 3.0 separately |
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.
The stable release update policy says that this should not go into 3.0. This would need to be raised at an OTC call and a vote taken to permit it into 3.0.
No problem, I'm more disturbed by possible regressions during refactoring |
if [ "$SRCTOP" != "$BLDTOP" ] ; then | ||
echo "Out of tree builds not supported with TLSFuzzer test!" | ||
exit 1 | ||
fi |
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.
Is there any particular reason why out of tree builds are not supported with this test? It was necessary to do with the gost test because it did not support multiple paths for include directories, however here I do not see any compilation depending on the OpenSSL sources. Or am I missing something?
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.
No, there is no real reason for that.
plan skip_all => "TLSFuzzer tests not available on Windows or VMS" | ||
if $^O =~ /^(VMS|MSWin32)$/; | ||
plan skip_all => "TLSFuzzer tests not supported in out of tree builds" | ||
if bldtop_dir() ne srctop_dir(); |
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.
Perhaps the test should be also skipped if the tlsfuzzer submodule is not present. Similarly to how some other external test check presence of the external sources.
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.
Not sure - we have submodules to ensure the presence of the sources, don't we?
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.
Yes, but you might want to run just some of the external tests. Of course you can always selectively run the individual tests, but... But yeah the gost external test recipe does not check for the presence of the gost sources either.
24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually. |
Merged. Many thanks! To be continued... |
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #17340)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #17340)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from #17340)
Hi, I see test failure of dayly "coverage" test:
what does that mean? |
I suspect lack of the submodules added for this test, speaking frankly. |
@beldmit would you please fix it? I'd recommend also adding the skip of the test in the test recipe if the submodule is not present. |
I can't do it before Monday, sorry |
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#17340) (cherry picked from commit cccbb4f)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#17340) (cherry picked from commit db87f89)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#17340) (cherry picked from commit e66c417)
This is a WIP PR to add TLSFuzzer external testing to openssl
Checklist