Phillip J. Eby wrote: > Okay, so how should we move forward? I drafted a testreactor module > earlier today, but it's not checked in and I don't have any tests for it > yet. I could add some simple self-tests tomorrow, and check it in, and > then you could experiment with running some tests against it, and let me > know how it works. What do you think?
Sounds good. But I realized a difficulty, see below. > With regard to the specific test code you're talking about, though, the > testreactor would have to run in real time, not simulated time, because > I wrote it assuming that the select() calls would always succeed with > zero delay (due to being loopbacks). In the test code you pointed me > to, there's an external server so there would actually be a need to run > with wall clock time. So, if that's what you're talking about (running I was going to say "forget the external server" and do everything by first recording a live session and then putting a mocket around the data that was recorded. However, SSL by design makes this approach hard because the server and client want to agree on some random key and every session is therefore different. Theoretically I could change the piece that chooses the random part to be deterministic. Not sure how hard that piece would be to find and how much would be involved in setting it so without affecting the real security of the system. There might be something like this already in OpenSSL's own test cases, but I'd have to go take a look. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
