Repository navigation
Conversation
Exposes HTTPClient.Configuration.tlsCustomVerification (NIOSSL backend) and .tlsCustomVerificationNetworkFramework (Network.framework backend), thin passthroughs into NIOSSLClientHandler's customVerificationCallback and Network.framework's sec_protocol_options_set_verify_block respectively. Neither hook carries any built-in pinning policy — the goal is to let a caller (e.g. a TrustEvaluator implemented downstream) fully own the accept/reject decision on whichever TLS backend actually negotiates the connection, including inspecting the full presented chain rather than just the leaf. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Exposes HTTPClient.Configuration.tlsLocalIdentityNetworkFramework: a thin passthrough into Network.framework's sec_protocol_options_set_local_identity, for direct (non-proxied) connections on Apple platforms. tlsConfiguration.certificateChain and .privateKey (the NIOSSL-shaped mTLS config) remain unsupported on this backend, same as before -- there's no public API to build a SecIdentity from raw bytes without a Keychain round-trip, so this hook takes an already-built SecIdentity rather than AsyncHTTPClient performing that round-trip itself. Tests cover both that the client certificate is actually presented to a server that requires one, and the negative control (connection rejected without it). Synthesizing a Keychain-backed SecIdentity inside an unsigned `swift test` process is itself unreliable -- the positive test skips rather than flakes when that round-trip can't complete, same limitation RequestDL's own RawBytesIdentityBuilder test suite already works around by only unit-testing its DER-parsing halves. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…oc comment Three double-backtick links in an unconditional doc comment pointed at symbols that don't exist in every build this repo's CI produces documentation for: tlsCustomVerificationNetworkFramework is canImport(Network)-gated (absent from the Linux symbol graph entirely), and TLSConfiguration.certificateVerification / NIOSSLCustomVerificationCallback both live in the NIOSSL module, which DocC can't resolve an unqualified cross-module link against in this build. Switched all three to plain code spans -- still readable, without a resolution DocC can't perform. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #910, which I closed after concluding that bundling a full SPKI-pinning implementation into
AsyncHTTPClientwas the wrong shape —URLSessiondoesn't do that either, it just hands callers a hook via its delegate and lets them build pinning (or anything else) on top. This PR is that hook, for both TLS backends this library uses:HTTPClient.Configuration.tlsCustomVerificationwires upNIOSSLCustomVerificationCallback, which NIOSSL already exposes onNIOSSLClientHandler— this just plumbs it through fromHTTPClient.Configurationinstead of requiring a caller to construct their ownNIOSSLClientHandler.tlsCustomVerificationNetworkFrameworkis the equivalent for direct (non-proxied) connections on Apple platforms that go through Network.framework instead of NIOSSL, which has no equivalent today.tlsLocalIdentityNetworkFrameworklets a caller present a client certificate (mTLS) over Network.framework by handing over aSecIdentitythey've already obtained. Related to Not supported features atTLSConfiguration#696, where @Lukasa mentioned bridging support here would be welcome — this stays conservative and doesn't attempt the Keychain round-trip itself (tlsConfiguration.certificateChain/.privateKeyremain the way to do this on the NIOSSL backend), it just accepts an identity the caller already has.Both new hooks are additive and only apply to the Network.framework code path; NIOSSL behavior (including proxied connections on Apple platforms, which always go through NIOSSL) is unchanged.