This will avoid build failures in the future when X509_STORE and
X509_OBJECT become opaque. Along the way, it does the following:
- Remove unnecessary NULL check for the object list (it's always
non-NULL, and STACK_OF(T) functions generally treat NULL as the empty
list).
- Use BoringSSL's ranged-for adapters for STACK_OF(T).
By using the X509_OBJECT accessor, rather than reaching into the union
directly, this also avoids a potential memory error in the future, if
you ever put non-X509 objects into your X509_STORE.
(X509_OBJECT_get0_X509 checks the type and returns NULL.)
TEST=rely on CI tests, this is refactor
Change-Id: Iafb8c06cfdfa86948119c229837b2e20b824f612
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206460
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: I3b33a03b4a9a14b76d55fe12f8cdefec4b3c3664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205633
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This is follow-up to https://dart-review.googlesource.com/c/sdk/+/174340, which moved construction of macos certificate list from boringssl structures from worker thread back to main thread, however it seems to have resulted in certificates in certificate list being prematurely released.
This cl explicitly passes/retains certificates lists to worker thread to be released after certificate trust is evaluated.
Avoid using deprecated SecTrustEvaluate if running on recent versions of OS.
Fixes https://github.com/flutter/flutter/issues/73971
TEST=flutter/examples/image_list on mac osx 10.13.6 simulator 10.3.1
Change-Id: I36829a9b236fab2bbbe952314ce277c436ea0e10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183620
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Boringssl data structures are not neccessary thread-safe, so should not be handled on certificate evaluator that runs asynchronously. That leaves only (potentially long-running) SecTrust call to be done by certificate evaluator.
Fixes https://github.com/flutter/flutter/issues/70800.
TEST=io/https_connection_closed_during_handshake_test.dart
Change-Id: I6f77f1efc9ec83c50e6bcc551c0f63d6465c763e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174340
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
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>
Brian Quinlan