On Monday 15 June 2015 12:14:47 Pascal Cuoq wrote: > Hello, > > I am working on a C interpreter that uses existing tests to find more issues > than simple execution does. In that it is comparable to Valgrind or UBSan. > It has different enough strengths and weaknesses compared to these existing > tools to make it worth using in addition to them, too. > > This C interpreter is already able to work its way through a majority of the > tests in OpenSSL's test directory, and indeed to find issues that occur > during the execution of these tests (RT #3891). I was wondering whether > anyone had, as a readily available artefact of fuzzing or quality assurance > campaigns, some additional test drivers beyond but in the same style as > those inside the archive. > > Tests for derived libraries such as LibreSSL or BoringSSL would also be > interesting.
not yet ready, but I'm working on a generic test suite for TLS: https://github.com/tomato42/tlsfuzzer/ the basic idea behind it is to have a non RFC compliant server or client and seeing if the peer responds correctly to malformed messages (In other words, it can very easily test openssl s_server process). I don't know if that matches the expected environment of your tool. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
