ACME

David:Only assumptions on my part, I'd guess that file is allowed to go big specifically related to the beta, via the ACM, or, at least in your example, it's borked - sqlite.org says this about size, otherwise:Avoiding Excessively Large WAL FilesIn normal cases, new content is appended to the WAL file until the WAL file accumulates about 1000 pages (and is thus about 4MB in size) at which point a checkpoint is automatically run and the WAL file is recycled. The checkpoint does not normally truncate the WAL file (unless the journal_size_limit pragma is set). Instead, it merely causes SQLite to start overwriting the WAL file from the beginning. This is done because it is normally faster to overwrite an existing file than to append. When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and its associated shared-memory file, to clean up the disk.So in the vast majority of cases, applications need not worry about the WAL file at all. SQLite will a

Hi, I began using Reality Composer on the iPad Pro about a year ago, approaching it from having taught 2D-3D graphics 20 year’s ago. Apple’s AR is the most exciting presentation format since QuickTime. I am in much the same position you are in...I have ‘content’, now how do I sew it together and into an app?. Apple has solid information on making apps in ‘normal product category domains’. AR is still a bit new. The difficulty of making the leap from ‘content’ to ‘app’ depends somewhat on your background with Xcode, along with the the complex’s and goals of your app, You also may or may not need an ‘app’ in the ‘AppStore’ sense; I’ve seen discussion of using QuickLook for viewing.reality files. If all you need to do is share your AR content, exporting a Reality Composer ‘scene’ as a .reality file can be a very useful way of making your ‘content’ available the way it functions within Reality Composer’s building environment. C You may also wish to look at SwiftPlaygrounds in iOS as a way to examine if your conte

If you want that one user only have one account in ACME, you can detect that the original_transaction_id is being used by another account, and inform the user that he has another account. If you decide to allow a user have different accounts in ACME, then that shouldn't be a problem because the user is the same with two accounts. If the user is the same, it shouldn't matter what account he used to log in. To share subscription between members of a family, Apple has now Family Sharing: https://developer.apple.com/documentation/appstoreservernotifications/notification_type#3733656

I am not aware of any sample code, which is really a shame. Without sample code, writing USB serial device drivers is a very obscure science. However, if you can influence the code on the USB device you are better off implementing the USB CDC ACM protocol. That way your device appears under /dev/tty* and /dev/cu* without the need to write a device driver. And best of all, it works on Windows and Linux as well - again without device drivers. And on macOS, you probably don't want to use the /dev/tty* device but rather the /dev/cu* device. /dev/tty* is from the old days when you had a modem connected to your serial port and your software would become active if there was an incoming call.

You're right that the ClientIdentifier can work similarly to the SCEP challenge. ClientIdentifier management systems amount to some kind of coordination between the ACME server and the system that's generating the configuration profile containing an ACME payload (usually the MDM server). There's many ways to arrange it: It could be that the ACME server and MDM server agree on some ClientIdentifier generation scheme based on increasing counters or timestamps, or the MDM server asks the ACME server to issue a ClientIdentifier to embed in the profile, or the MDM server generates them and the ACME server verifies them when a certificate is requested. But this is ultimately weak evidence. If the ClientIdentifier is fumbled at any step of the way, someone else could use it. That's why the only specifically recommended use is as a rate limiting system, so that the ACME server can quickly reject clients that don't have valid ClientIdentifiers. So how does the ACME

It would be great if the device could attest that it is under management and have an OID for the check-in URL or the APNS topic is registered against. This might eliminate the ACME server's need to authorize a request against the MDM server or help improves the validation of the request etc. The only properties that could potentially appear in attestations are things that the Secure Enclave did. It's the OS's responsibility to enroll the device and keep track of the check-in URL, push topic, and other management-related properties. So to attest it, the OS would have to tell the Secure Enclave these properties. A compromised OS could lie to the Secure Enclave about these management properties. So to trust attestation of those properties, you'd have to trust the OS as well. And if you're trusting the OS, the attestation of that property isn't giving you any additional security over just asking the OS to report the property directly.

This is a bug in the ACME client in iOS, iPadOS and tvOS that causes the nonce to not appear in the attestation leaf certificate. This issue should be fixed in a future release.