Search results for

“eskimo”

37,165 results found

Post

Replies

Boosts

Views

Activity

Reply to macos 26 - socket() syscall causes ENOBUFS "No buffer space available" error
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
May ’26
Reply to AUV3 effects in Swift Playground iPad - info.plist
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.
May ’26
Reply to LAContext and its usage in context of Local Authentication
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
Topic: Privacy & Security SubTopic: General Tags:
May ’26
Reply to Are App Attest or DeviceCheck supported on any Macs?
[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
Topic: Privacy & Security SubTopic: General Tags:
May ’26
Reply to codesign tool generates "timestamps differ by XXX seconds" error
[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
Topic: Code Signing SubTopic: General Tags:
May ’26
Reply to Local network permission
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
May ’26
Reply to Developer ID Application certificate creation
[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
May ’26
Reply to The callback is not triggered when the app is launched from a terminated state via the notification action
[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
May ’26
Reply to How much practical benefit is there to XPC-based privilege separation?
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
Topic: Privacy & Security SubTopic: General Tags:
May ’26
Reply to tahoe 26.4.1 chdir(2) problem
[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
May ’26
LAContext and its usage in context of Local Authentication
While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if prese
1
0
346
May ’26
LAContext and its usage in context of Local Authentication
While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if prese
2
0
389
May ’26
Reply to Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution
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
Topic: Programming Languages SubTopic: Swift Tags:
May ’26
Reply to macOS 26 – NSSound/CoreAudio causes SIGILL crash in caulk allocator
[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
Topic: Media Technologies SubTopic: Audio Tags:
May ’26
Reply to macos 26 - socket() syscall causes ENOBUFS "No buffer space available" error
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
Replies
Boosts
Views
Activity
May ’26
Reply to AUV3 effects in Swift Playground iPad - info.plist
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.
Replies
Boosts
Views
Activity
May ’26
Reply to LAContext and its usage in context of Local Authentication
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
Topic: Privacy & Security SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to Are App Attest or DeviceCheck supported on any Macs?
[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
Topic: Privacy & Security SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to codesign tool generates "timestamps differ by XXX seconds" error
[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
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to Local network permission
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
Replies
Boosts
Views
Activity
May ’26
Reply to Developer ID Application certificate creation
[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
Replies
Boosts
Views
Activity
May ’26
Reply to The callback is not triggered when the app is launched from a terminated state via the notification action
[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
Replies
Boosts
Views
Activity
May ’26
Reply to How much practical benefit is there to XPC-based privilege separation?
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
Topic: Privacy & Security SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to tahoe 26.4.1 chdir(2) problem
[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
Replies
Boosts
Views
Activity
May ’26
Reply to LAContext and its usage in context of Local Authentication
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
Topic: Privacy & Security SubTopic: General Tags:
Replies
Boosts
Views
Activity
May ’26
LAContext and its usage in context of Local Authentication
While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if prese
Replies
1
Boosts
0
Views
346
Activity
May ’26
LAContext and its usage in context of Local Authentication
While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if prese
Replies
2
Boosts
0
Views
389
Activity
May ’26
Reply to Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution
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
Topic: Programming Languages SubTopic: Swift Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to macOS 26 – NSSound/CoreAudio causes SIGILL crash in caulk allocator
[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
Topic: Media Technologies SubTopic: Audio Tags:
Replies
Boosts
Views
Activity
May ’26