After committing changes, I would like to push them to a repository. I select the "Source Control" => "Push" command and expect the count of commits which differ from the report to disappear. They do not. I enabled Git trace2 API parameters in my .gitconfig file to try and resolve the problem. To prove that output is written to the trace log files set up wtih the trace2 API, I enable the Inspectors section, then click on different commits to see the git trace output to the logfiles. When I execute 'git push' from the command line, I see the exchange with the remote repository. If I perform the "Push" command from within Xcode, I don't see any output to the logfiles. I then configured Wireshark to capture the exchange between my computer and the repository. I see the exchange for both the terminal and Xcode environment.I suspect that Xcode uses the internal /usr/bin/git for some commands, and its own internal code for the "Source Control" menu commands. This could explain why I see the traces for some Git actions but not others. Has anybody encountered a 'push' problem within Xcode and resolved the problem?

I am working on code for the iOS platform to handle connections to servers, handle the trust evaluation, policy management, and general authentication.During the authentication process, a certificate is evaluated to verify all the certificates are valid back to the anchor certificate. If this passes, the contents of the certificate can be trusted. Next, the trust object checks the certificate against a policy. The two policies I use are the basicX509 and sslServer policies.( You can generate the policy's keys/values by setting a breakpoint on the following code: NSString *hostname = @"your.dNS.name"; SecPolicyRef secPolicyRefSSL = SecPolicyCreateSSL(TRUE,(__bridge CFStringRef)hostname); OSStatus osStatus = SecTrustSetPolicies(secTrustRef, secPolicyRefSSL)--> if (osStatus != errSecSuccess)then in the debugger, issue "po secPolicyRefSSL" which displays the description containing oid, name, and options.The Apple SSL Policy = x509Policy + a few more key value pairs. You can create the basic x509 policy instead of SSL policy to see them.)The Apple SSL Policy key value pairs ('options') are as follows: BasicConstraints = 1; BlackListedLeaf = 1; CriticalExtensions = 1; ExtendedKeyUsage = ( ... ) GrayListedLeaf = 1; IdLinkage = 1; KeySize = {42 = 2048;73 = 256;}; NonEmptySubject = 1; SSLHostname = "hostname"; ServerAuthEKU = 1; SignatureHashAlgorithms = (SignatureDigestMD2,SignatureDigestMD4,SignatureDigestMD5,SignatureDigestSHA1); SystemTrustedCTRequired = 1; TemporalValidity = 1; ValidityPeriodMaximums = 1; WeakKeySize = 1; WeakSignature = 1;The policy check looks at the key value pairs in the policy and runs those policy requirement checks. If any do not pass, they appear in the SecTrustResultDetails key of the SecTrust object.So for example, I created a certificate that uses an RSA key size of 512 bits. The policy states it expects a weak key size test to pass as seen with the "WeakKeySize=1" key value pair. This had better fail. And it does, by failing the trust's policy requirements and returning 'WeakKeySize=0".As another example, I created an 'SSL Server' certificate with a validity period of 5000 days. But, since the policy has 'ValidityPeriodMaximums = 1', the policy runs a test that checks that the maximum of 825 days is not exceeded. It too will fail and return 'ValidityPeriodMaximums = 0'.I figured out the meaning of and tested most of these with the following exceptions: IdLinkage BlackListedLeaf GrayListedLeaf SystemTrustedCTRequired CriticalExtensions BasicConstraintsAssuming the 'CT' in SystemTrustedCTRequired is for 'Certificate Transparency', I know for a fact that a test server I am using with in-house anchor certificates do not participate in Certifcate Transparency protocols. How can my iOS clients connect to a server when SystemTrustedCTRequired policy is required to pass? It must be doing something else.Anybody know the meanings of these policy requirements? Any API documentation out there or iOS/macOS header files with these details?References:Policy OID definitions https://opensource.apple.com/source/libsecurity_asn1/libsecurity_asn1-29908/asn1/appleoids.asnRequirements for trusted certificates in iOS13 and macOS 10.15 (This is the human readable form for some of the key value policy pairs above) https://support.apple.com/en-us/HT210176Why does the hostname need to match the dNSName in the certificate? (this is the SSLHostname policy requirement)from https://tools.ietf.org/html/rfc2818 "Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."from https://support.apple.com/en-us/HT210176 "TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted."

I am working on code to handle connections to servers, handle the trust evaluation, policy management, and general authentication.As part of the Server Authentication challenge, when the delegate method URLSession:didReceiveChallenge:completionHandler receives a NSURLAuthenticationMethodServerTrust challenge, I add a trusted certificate anchor to the trust object using the method SecTrustSetAnchorCertificates. This allows the trust to pass its evaluation when applying the SSL Policy; because it can find the intermediate certificate (the anchor certificate I just configured in the SecTrustSetAnchorCertificates method).Everytime a new session is created, the authentication process repeats and the code loads the anchor certificate. Then I read this:(reference: https://developer.apple.com/library/archive/technotes/tn2232/_index.html#//apple_ref/doc/uid/DTS40012884-CH1-SECTRUSTEXCEPTIONS)Section: Missing Intermediate Certificates "On iOS, if your app adds the intermediate certificate to its keychain, the trust object will use it automatically."So, I thought this implied if I add the trusted anchor certificate to the app's keychain, the trust object would use it automatically and I would not have to use the SecTrustSetAnchorCertificates everytime. However, this fails with:TrustResultDetails : MissingIntermediate : 0Policy requirements not met: MissingIntermediate : Could not find a certificate in the chain.I have correctly added the certificate to the KeyChain using the API method: SecItemAdd and have verified the certificate is indeed in the keychain using the method: SecItemCopyMatching. So, even though the certificate is loaded correctly in the Keychain, the trust object is not using it.Is there some other API to configure to get this to work? Do I have to configure the URLSession to look in the KeyChain for certificates? Do I have to set an attribute when loading the anchor certificate that it is to be trusted? My fallback is to use the original method. This enhancement seemed to have made the process more efficient though.NB: the original method, the SecTrustSetAnchorCertificates method, configures a single anchor certificate that is allowed to be trusted ('certificate pinning'). I don't know how the Security API uses built-in anchor certificates when evaluating trust and whether 'certificate pinning' would be lost if I add the certificate to the Keychain. Does the trust look at my app's keychain for certificates as well as the built-in set of certificates (i.e. its no longer just looking for a single certificate)?

I am working on code to handle connections to servers, handle the trust evaluation, policy management, and general authentication. The issue I have is in regards to client authentication.The code handles an NSURLAuthenticationMethodClientCertificate challenge from a server. In the handler, the code responds with a credential containing a bad certificate on purpose, to test how the code will respond to the expected server handshake failure.Instead of being handled in the NSURLSessionTaskDelegate URLSession:task:didCompleteWithError method, the URLSession:taskIsWaitingForConnectivity is called. I breakpoint here and see the following in the debugger:(I removed the timestamps)[BoringSSL] boringssl_context_handle_fatal_alert(1872) [C1:2][0x1016266a0] read alert, level: fatal, description: bad certificate[BoringSSL] boringssl_session_handshake_error_print(111) [C1:2][0x1016266a0] 4317227128:error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE:/BuildRoot/Library/Caches/com.apple.xbs/Sources/boringssl/boringssl-283.60.3/ssl/tls_record.cc:587:SSL alert number 42[BoringSSL] nw_protocol_boringssl_handshake_negotiate_proceed(726) [C1:2][0x1016266a0] handshake failed at state 12288[] tcp_input [C1:3] flags=[R.] seq=4246551641, ack=1214174613, win=977 state=FIN_WAIT_1 rcv_nxt=4246551641, snd_una=1214174613[] nw_endpoint_handler_copy_flow_path [C1 192.168.134.65:7323 waiting path (satisfied (Path is satisfied), interface: en0, ipv4, dns)] Endpoint handler is not flowI see the expected response on the first line; bad certificate. Is there any API to retrieve this low-level error message from BoringSSL or URL Loading System API? This would allow me to check for an error, retrieve the error, and process the error. The code could then call a completionHandler to indicate a server connection failure.Right now the code will wait for the timeout period to expire, then call the NSURLSessionTaskDelegate URLSession:task:didCompleteWithError with a 'request timed out' error. Problem with that, is I still don't have any access to the root cause of the problem to indicate a server connection problem in an alert window.