For testing purposes.
Change-Id: Ied1b130e805bcf8cc5d1bd30a1ba5049d6f13a6d
Reviewed-on: https://boringssl-review.googlesource.com/17665
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
When testing against a browser, multiple connections will be made in
parallel. Keeping the same listening socket lets the other connections
queue up at least rather than fail with ECONNREFUSED. Of course, this is
still far from a realistic server.
Change-Id: I984fb29da4bf8808eb40938b12782dc1730f2e19
Reviewed-on: https://boringssl-review.googlesource.com/17405
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Ifbfae883638b35bb274f2002bc53fbba77c7aa85
Reviewed-on: https://boringssl-review.googlesource.com/8821
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We currently have the situation where the |tool| and |bssl_shim| code
includes scoped_types.h from crypto/test and ssl/test. That's weird and
shouldn't happen. Also, our C++ consumers might quite like to have
access to the scoped types.
Thus this change moves some of the template code to base.h and puts it
all in a |bssl| namespace to prepare for scattering these types into
their respective headers. In order that all the existing test code be
able to access these types, it's all moved into the same namespace.
Change-Id: I3207e29474dc5fcc344ace43119df26dae04eabb
Reviewed-on: https://boringssl-review.googlesource.com/8730
Reviewed-by: David Benjamin <davidben@google.com>
This change adds support for doing an SMTP STARTTLS dance before a TLS
handshake when using the tool. This is useful for poking at SMTP
servers.
Change-Id: I04cd60d02d3377cce83e412d62e3257235a19116
Reviewed-on: https://boringssl-review.googlesource.com/8662
Reviewed-by: David Benjamin <davidben@google.com>