The Documentation says that in order to "reset the account on Business Chat Sandbox and restart the first-run experience, visit the reset page". However, I have been unable to find said page. Does anyone know where it is located?

I want to use the SecAsn1-APIs (cf. https://developer.apple.com/documentation/security/asn_1) in a Xcode 12 playground. Since in order to use those it is not sufficient to simply import Security I am trying to make them available as a system library target (as per https://github.com/apple/swift-package-manager/blob/263171977ebcd47f4aaca1202cff5a96c5158a64/Documentation/Usage.md#import-system-libraries) instead, but I don't seem to be getting anywhere. Am I on the right track with this?

Is there any information about the new Apple Pay Issuer Extensions other than the WWDC video - https://developer.apple.com/videos/play/wwdc2020/10662/?time=730? The API docs (e.g. here - https://developer.apple.com/documentation/passkit/pkissuerprovisioningextensionhandler, here - https://developer.apple.com/documentation/passkit/pkissuerprovisioningextensionauthorizationproviding) all say "No overview available."

Hi everyone, I'm lost here. Our CI builds on Jenkins nodes every now and then get into a state where Check Dependencies fails with exit status 65 since allegedly the file pointed to by the CODE_SIGN_ENTITLEMENTS build setting cannot be opened. The file is present however, since it is checked out from version control and its permissions seem to be fine as well. We do run a pre-action script before the build action that modifies this file to enable us to build with different sets of entitlements, though. This happens with both the old and the new build system by the way. Is it possible that pre-action scripts somehow run asynchronously or that .entitlements files are handled differently during Check Dependencies?

From man arc4random - x-man-page://arc4random (on macOS 10.15): The original version of this random number generator used the RC4 (also known as ARC4) algorithm.  In OS X 10.12 it was replaced with the NIST-approved AES cipher Does this hold true for iOS as well and if so from which version on?

I currently have two valid Apple Distribution certificates (old and new, say) in my login keychain (which Xcode recognises in Settings > Accounts) and a project with a manual code signing setup such that a provisioning profile which references the old certificate is specified for the PROVISIONING_PROFILE_SPECIFIER build setting. While building, though, Xcode complains about the profile not containing some signing certificate (which I assume refers to the new one and which would be expected since I have yet to update it) and fails the build. This effectively means that I cannot have two valid certificates in the keychain and use two profiles where one references the old and the other the new certificate. Am I missing something here?

OAEP (i.e. Optimal Asymmetric Encryption Padding) as defined in RFC 2437 is parameterized by the choice of hash function and mask generation function. The hash function is usually either SHA-1 or SHA-2 while the only mask generation function defined is MGF1 which itself is based on a hash function. In the Security.framework this padding scheme is available as OAEP (deprecated as of iOS 15) and as properties of the SecKeyAlgorithm structure, e.g. rsaEncryptionOAEPSHA1. The documentation for both only reads No overview available but from the comments in SecKey.h can be gleaned that at least for rsaEncryptionOAEPSHA1 data is padded using OAEP padding scheme internally using SHA1. So it seems that while using SecKeyAlgorithm the choice of hash function corresponds to selecting a property of the structure; the question that remains is whether this hash function is used for both the encoding scheme and the mask generation function. I suppose that this is in fact the case, but I am unable to find anything corroborating this.

As a follow-up to a Networking lab conversation I had on Tuesday I have the following question: Is there a way to use nscurl to connect to a server that requires client authentication by providing a client certificate? None of the documented options seem to allow that, but maybe there is an undocumented one...

I am slightly confused as to how I am supposed to maintain persistent access to a SecureEnclave.P256.Signing.PrivateKey. Do I have to persist the key myself (using its dataRepresentation property and code along the lines of Storing CryptoKit Keys in the Keychain or is there another persistent reference to the key inside the Secure Enclave that I can use later?

The documentation states: iOS, iPadOS, macOS, and tvOS apps can share a single target. watchOS apps remain in a separate target. Why is that?

Is it possible to send remote notifications via APNs to an iOS app from two provider servers one of which uses certificate-based authentication while the other uses token-based authentication? The documentation states: To send notifications, your provider server must establish either token-based or certificate-based trust with APNs However, this only applies to one server and not two. StackOverflow: https://stackoverflow.com/a/51726097

I am trying to use SecItemUpdate in order to change the kSecAttrAccessControl value on a private key protected by the Secure Enclave as well as an .applicationPassword - which I want to change. I have been unsuccessful getting the query and attributesToUpdate dictionaries right though, with SecItemUpdate returning either errSecParam, errSecNoSuchAttr or errSecAuthFailed. Am I on the right track here or am I trying to do something that is not possible?

Is there an API to create a .logarchive file from the contents of e.g. a OSLogStore?

The unified logging system on iOS can allegedly be configured by means of configuration profiles (as alluded to e.g. here), but documentation as to how to do that seems to be scarce. I am especially interested in whether it is possible to create a profile that auto-expires after a predefined time period (as the one for use with Apple Pay available here does). Can anyone point me in the right direction?

We are seeing crashes lately that seem to be caused by PAC, but we are not yet building for the arm64e architecture as advertised here. Is it likely that adopting that architecture will alleviate these crashes?