Running trust evaluation system api call on worker thread effectively unblocks main isolate when it attempts to establish https connection.
Execution of the worker thread is implemented via dart native port infrastructure which allows to run C++ code as a dart message handler.
TrustEvaluateHandlerFunc (if provided by platform-dependent SSLCertContext) is that handler, only mac(ios) implementation provides it.
Asynchrony of CertificateVerificationCallback (for mac/ios) is implemented via [ssl_verify_retry] return code which allows to suspend ssl handshake until certificate trust is confirmed.
When dart's _RawSecureSocket.secureHandshake() method that initiated ssl's handshake received this return code it knows it has to wait for a future that is completed by another callback([rpEvaluteResponse]) that waits for trust evaluation handler response.
rpEvaluateResponse purpose is to listen for response from TrustEvaluateHandler and also invoke user-provided [badCertficateCallback] that can override trust decision for a given connection request, for a given certificate.
Once that future is completed and CertificateVerificationCallback knows whether to trust a certificate or not, _secureHandshake retries ssl handshake.
Bug: https://github.com/dart-lang/sdk/issues/41519
Change-Id: Ifee18639c78099ec77cad50000444bc6c7b9369b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165520
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Previously we would compile in implementaitions of native calls for
IO functions that would never be used. This CL provides implementations
that throw a Dart exception if they're called by mistake. It also uses
a DART_IO_DISABLED preprocessor define to clean up the build files and
check that we're not including code we shouldn't.
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1839463002 .
Implements SecurityContext.setTrustedCertificates in terms of the new
function. This requires setTrustedCertificates to return a Future,
and removing the `directory` named argument as it is not possible to
implement with BoringSSL without blocking IO.
R=whesse@google.com
Review URL: https://codereview.chromium.org/1665433002 .
This is the first step toward removing blocking IO calls from
the implementation of the SecurityContext API.
Using a buffer rather than a file name API will probably be needed
for implementing SecurityContext and SecureSocket with platform
specific built-in APIs on iOS/Mac/Windows rather than BoringSSL.
related #8227R=whesse@google.com
Review URL: https://codereview.chromium.org/1616073004 .
This replaces the NSS secure networking library from Mozilla
with the BoringSSL library from Google. This library, based
on OpenSSL, reads certificates from files in PEM format, rather
than storing certificates and keys in a SQLite database, the
way NSS does. There will be a blog post, changelog entries,
and other documentation of the breaking changes.
Review URL: https://codereview.chromium.org//1319703002 .
Brian Quinlan