“eskimo”

I can’t say much more than what you can see in Feedback Assistant: The bug has been seen by the right folks. It’s not fixed in any released or seeded beta OS. Oh, there is one thing I can add. In this bug you asked whether we can reproduce the problem, and I can confirm that, yes, we can. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, lemme see if I understand this correctly: You’re using Swift Playground 4.7 on iPad. You’ve created an app playground. You’re trying to add an Info.plist property to your app, one that’s not directly support by the Swift Playground app. Is that right? If so, then sadly there’s no good way to do this. The Swift Playground app doesn’t have a UI that lets you add arbitrary Info.plist properties, and there’s no supported way to provide an ‘template’ Info.plist file [1]. Oh, and please do file your own enhancement request describing what you’re trying to do and what you’d like Swift Playground to support. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] If you search the ’net for FB9824864 you’ll find an unsupported way to do that. I’m not sure if it still works.

I’m pushed for time right now, so I’m just gonna touch this point: [quote='826279021, 23122K, /thread/826279, /profile/23122K'] I would love to share it, but the domain is not permitted) [/quote] You can share any link as long as you do so in the clear. See tip 14 in Quinn’s Top Ten DevForums Tips. So please do share that link. Hopefully I’ll see your reply when my life is a little more calm |-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887790022, SammySmallman, /thread/682488?answerId=887790022#887790022, /profile/SammySmallman'] This appears to still be the case in 2026... [/quote] Correct. Usually I’d suggest that you file an enhancement request for this feature on the Mac, but in this case I can assure you that the App Attest team is well aware of the desire for that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='826273021, jaikiran, /thread/826273, /profile/jaikiran'] we even printed the details of an already signed binary … and that prints [a] similar warning message [/quote] OK. Lemme explain how that message comes about, and I think you’ll be able to extrapolate from there. The codesign tool calls SecCodeCopySigningInformation and looks at two properties: kSecCodeInfoTime and kSecCodeInfoTimestamp. If the values differ significantly (3 minutes IIRC) you get this message. While these properties are covered reasonably well by the documentation, the best source of info about them is the doc comments in . In summary: kSecCodeInfoTimestamp is secure, having been issued by Apple’s timestamp service. For more on that, see the Certificate expiration section of TN3161 Inside Code Signing: Certificates. kSecCodeInfoTime is based on your Mac’s time setting. So I suspect that the Mac doing the signing has a clock that’s way of sync with reality, so these two values end up significantly different, and thus this problem

TN3179 Understanding local network privacy has a lot of background on this technology. Please read it through and then write back with any follow-up questions you have. Oh, and it’d be helpful to know when platform you’re targeting. There have been some recent fixes to macOS that mean that, on the Mac side, it’s best to test with the very latest version. [quote='826268021, Xcaliber, /thread/826268, /profile/Xcaliber'] Is Apple planning to introduce a dedicated authorization API … ? [/quote] I can’t talk about The Future™, but the fact that local network privacy is 6 years old new and we still don’t have an API can be construed as some sort of signal. Having said that, the lack of this API is a common stumbling block and I encourage you to file your own enhancement request for it. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] we were posed with the option of choosing a Developer ID Certificate Intermediary [/quote] Oh, that’s a new one. [quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] Can you please let us know which Developer ID Certificate Intermediary we should choose … ? [/quote] I don’t think there’s a one-size-fits-all answer to that, which is why we give you the choice. My general advice is that you pick the new one, but the old one might make sense if: You have infrastructure that relies on ancient versions of Xcode (or the Command Line Tools package). Or infrastructure that’s tied to a specific intermediate. Picking the new one may require you to install the new intermediate on your build infrastructure, but that’s not a particularly onerous task. From a deployment perspective, this choice shouldn’t matter. When codesign signs code, it builds a chain of trust and embeds that full chain into the code signature. So when a Mac goes to verify the sig

[quote='887766022, DTS Engineer, /thread/826318?answerId=887766022#887766022'] You should check with the support resources provided by the 3rd party [/quote] Right. Alternatively, you can try reproducing this by calling URLSession directly. I suspect that’ll work, which confirms that this is something that your need to discuss with your third-party tooling vendor. OTOH, if you can reproduce it with URLSession, then you’ll calling an Apple API and we can help you here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are a couple of ways XPC services can help with security. The first is the one you’re talking about, that is, where you give the XPC service elevated privileges. Your ‘delete a user’ example isn’t great though, because deleting arbitrary users is problematic and it also requires BSD privileged escalation. So let’s consider a different example. Consider a sandboxed app that wants to install an item in ~/Library/PDF Services. There are no BSD level blocks to doing that, but it is blocked by the App Sandbox. To get around that block you sign the app with the com.apple.security.temporary-exception.files.home-relative-path.read-write temporary exception entitlement. Cool, problem solved! Note For links to more about temporary exception entitlements, and the App Sandbox in general, see App Sandbox Resources. However, if your app gets compromised then it might install arbitrary stuff into ~/Library/PDF Services, which isn’t great. So instead you move that code into an XPC service and the app tells the XPC serv

[quote='826314021, ehr3, /thread/826314, /profile/ehr3'] As per the man page, this IS NOT what it is supposed to do. [/quote] Please post the bit of the man page that makes you think that. Because when I search the chdir man page the only mention I see of the text sym or link is this: [ELOOP] Too many symbolic links were encountered in translating the pathname. This is taken to be indicative of a looping symbolic link. which suggests that it is intended to follow symlinks. And AFAIK this has been the case ever since symlinks were introduced. Notably, the Posix spec has similar text and AFAIK this is standard across all Unices. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. I’m a bit confused as why you’re still seeing problems here. I’ve tried various things in my testing and they all worked just fine. Clearly there’s some sort of environment issue in play, like perhaps your project settings. Given that, I recommend that you create a test project, one that’s cut down to show just the issue you’re trying to resolve here. The act of creating such a project might help you resolve the issue. If not, you can share a link to the project here and I’ll be happy to take a look. Note You might need to post the link in the clear. See tip 14 in Quinn’s Top Ten DevForums Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887591022, Yanziyi, /thread/824550?answerId=887591022#887591022, /profile/Yanziyi'] I've encountered the same issue [/quote] OK. Then I have the same question for you: How reproducible is it? We’ve definitely seen bug reports about this. The conclusion is that, yeah, something is corrupting memory. It’s hard to be sure what that is, but we’ve made some changes to the OS to help debug it (r. 170652193). However, those changes are not yet in any released or seeded version of macOS. If you’re hitting this, try running your app under the standard memory debugging tools. Those tools aim to turn hard-to-reproduce memory management issues into reproducible ones, and if they do that in this case then that’ll be a significant step in the direction of a fix. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com