Search results for

“codesign”

3,223 results found

Post

Replies

Boosts

Views

Activity

Pkg installation package uploaded to macstore email prompt ITMS-90296
Project Background: I developed a Mac project using Electron and VSCode Successfully uploaded the packaged pkg using Transporter, However, I will receive an email informing me that there are some issues with the project: ITMS-90296: App sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' Here is my packaging process: Generate an app using the electron packager tool Sign the app using @ electron osx sign (version
2
0
693
Nov ’24
Reply to errSecInternalComponent when trying to codesign an app through SSH
Ok, found a solution after 10 hours. When running standalone multiple SSH commands the unlock-keychain doesn't stick between commands, running: ssh ${REMOTE_SERVER} security unlock-keychain -p /Users//Library/Keychains/login.keychain-db && codesign -vvv --deep --force --verify --verbose --timestamp --options runtime --sign Developer ID Application: /tmp/$BUILD_ID/ui-app/.app Fixed it. Good luck :)
Nov ’24
errSecInternalComponent when trying to codesign an app through SSH
Hi, I'm trying to ssh into another machine, copy an app into that machine and codesign it using my Dev ID Application certificate, then copy it back to my original machine. I'm getting the errSecInternalComponent error when running codesign. This is the bash script I'm running: ssh ${REMOTE_SERVER} security -v unlock-keychain -p /Users//Library/keychains/login.keychain-db ssh ${REMOTE_SERVER} codesign -vvv --deep --force --verify --verbose --timestamp --options runtime --sign Developer ID Application: /tmp/$BUILD_ID/ui-app/.app ssh ${REMOTE_SERVER} codesign -dv --verbose=4 /tmp/$BUILD_ID/ui-app/.app I've tried to follow all the available info found online, managed to sign it successfully through the machine's UI, set the ACL of the private key to ALLOW ALL, restarted the keychain service, tried with the system keychain, approved all pop ups through the UI. Still with no luck through the SSH session. Any help would be greatly appreciated. Thanks!
2
0
586
Nov ’24
Pkg installation package uploaded to macstore email prompt ITMS-90296
Hello! I encountered an issue while packaging and uploading the project to the Mac store. I received an email stating: ITMS-90296: App Sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. Though you are not required to fix the following issues, we wanted to make you aware of them: ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight
18
0
1.8k
Nov ’24
Gatekeeper scans app before it finishes copying
Hi all, I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because it's damaged, even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app. I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done? I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation. Maybe there's a more elegant way? Thanks!
3
0
630
Nov ’24
Reply to Codesign dylib/framework with entitlements
[quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] Is it correct to codesign dylib/framewoks with entitlements? [/quote] No. It’s never correct to do that. Entitlements are only useful when applied to a main executable and can cause problems when applied to library code. [quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] Is this even allowed? [/quote] Depends on what you mean by “allowed”. It never does anything useful. It won’t be caught by either App Store Connect or notarisation. In most cases it’s benign. In some specific cases it will cause your program to be blocked by the trusted execution system. [quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] I know of at least one app that has passed notarization checks as well. [/quote] The goal of the notary service is for software to be “checked by Apple for malicious components”. It doesn’t audit your program for correctness, except as necessary to perform that goal. You can notarise a progr
Topic: Code Signing SubTopic: Entitlements Tags:
Nov ’24
Reply to iOS 18 启动崩溃 main_executable_path_missing
In addition,app recently encountered a dyld crash similar to this crash on iOS15.5, which looks somewhat similar to the current crash. Not sure if it's the same, but it looks similar.See if it helps the analysis.I have a file bug,number is FB15719846 (iOS 15.5 dyld Crash),hope it helps.Thanks. Hardware Model: iPhone14,5 Process: XxxxxxXXX [265] Path: /private/var/containers/Bundle/Application/DAC8B886-80BB-48DB-916D-DBB854B69DFD/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.3 (81300) AppStoreTools: 15F31e AppVariant: 1:iPhone14,5:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [409] Date/Time: 2024-08-20 11:59:31.9614 +0800 Launch Time: 2024-08-20 11:37:02.3165 +0800 OS Version: iPhone OS 15.5 (19F77) Release Type: User Baseband Version: 1.61.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGKILL - CODESIGNING) Exception Subtype: UNKNOWN_0x32 at 0x00000001048d0000 Exception Codes: 0x0000000000000032, 0x00
Nov ’24
Codesign dylib/framework with entitlements
Is it correct to codesign dylib/framewoks with entitlements? My understanding is that only executables need to have the entitlement and the dylibs loaded in that process will automatically inherit those entitlements. However, I am seeing a lot of scripts on the internet that are signing dylibs as well with entitlements. For eg - # sign *.dylibs find $APP_BUNDLE -type f -name *.dylib -exec codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements $ENTITLEMENTS_FILE --sign $SIGNING_IDENTITY {} ; Is this even allowed? I know of at least one app that has passed notarization checks as well. If allowed, can a dylib have more entitlements than the process that loaded it?
2
0
1k
Nov ’24
Reply to "How to" for dext distribution
It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now. FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere else. First, I had changed the bundle ID of my dext to what it should be, after learning that the bundle ID ought to be an extension of the owning application's bundle ID. This is common practice and what Xcode does by default, but I don't believe the system actually requires it, as it needlessly restricts/complicates what's possible without any real benefit. It's been
Nov ’24
Reply to Xcode Project with Framework - Library not loaded - mapping process and mapped file have different Team IDs
I found this topic while trying to solve pretty much the same issue in my project, and since I've found a solution, I was thinking to share it in case it would help someone else in the same situation. Turns out the framework in the build folder is not signed, so it couldn't be loaded properly. At the same time the framework located in the resulted application bundle is signed properly, but it was not used for some reason. You can check the signature of the framework with codesign -d -r - Shared.framework command. I was able to solve the issue by adding following properties to the build settings, hope it will help someone LD_RUNPATH_SEARCH_PATHS = @executable_path/Frameworks LD_RUNPATH_SEARCH_PATHS[sdk=macosx*] = @executable_path/../Frameworks Essentially it loads frameworks from the expected location for the iOS build and the other location for the macOS build (the bundle structure is different depending on the destination).
Nov ’24
Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
[quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Are there any restrictions regarding this? [/quote] Yes. [quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Is there a way to bypass these restrictions? [/quote] No. App bundles are read-only by design. This isn’t a new requirement [1], but recent changes in macOS’s trusted execution system mean that it’s more important to follow the rules. To quote Embedding nonstandard code structures in a bundle: A bundle is a read-only structure. All Apple platforms except the Mac enforce this requirement at runtime. On iOS, for example, any attempt to modify your app’s bundle at runtime will fail with an error. The Mac may or may not enforce this requirement at runtime, depending on the context, but modifying your app’s bundle isn’t supported because it breaks the seal on the app’s code signature. So your current goal, having the app modify itself, is unsupported, likely to cause problems today, and even more likely to cause problems i
Topic: Code Signing SubTopic: General Tags:
Nov ’24
Unable to Write Files Within App Bundle After Codesigning and Notarization
Codesigned and notarized app cannot directly write files inside the app bundle (neither in my.app/Contents/Resources/ nor my.app/Contents/MacOS/). Are there any restrictions regarding this? Is there a way to bypass these restrictions? Here is the situation I encountered: The main app contains several sub-apps and sub-executables. When the main app calls the sub-apps or sub-executables, it can write files within the app bundle, but when executed directly, it cannot write files. The app is usually opened using the GUI, and when using the command line, neither the main app nor the sub-apps/sub-executables can write files within the app bundle. My codesigning environment is: Sonoma 14.0 on mac mini M1. I manually sign the app directly using the codesign command in CI instead of using Xcode. The process will traverse all of the files and sub-apps in the app folder and sign them from the deepest paths to the shallowest paths. I also tried applying this process to other applications, but a
3
0
825
Nov ’24
Reply to Content Filter: sourceAppAuditToken empty only for Firefox
This is clearly a bug. There should always be an audit token because some process must’ve started the flow. The next time you see this, please trigger a sysdiagnose log as soon as you see it, and then file a bug with that log. And once your done, I’d appreciate you posting the bug number here, just for the record. If you’re doing this on a ‘victim’ machine then you should enable additional NE logging via the VPN (Network Extension) for macOS instructions on our Bug Reporting > Profiles and Logs page. If you’re doing this on a real machine, you can enable that extra logging, but please consider the privacy impact. [quote='767822021, terransw, /thread/767822, /profile/terransw'] Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome: [/quote] That’s definitely not relevant. Chrome is opting in to some additional security checks, but Firefox gets most of those anyway because it’s enabled the hardened runtime (shown as runtime in that output). If yo
Nov ’24
Content Filter: sourceAppAuditToken empty only for Firefox
Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token. Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid. Debugging: My logging shows audit token is empty for Firefox Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for: com.apple.networkextension debug 11:22:07.024588-0300 Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null) com.apple.networkextension debug 11:22:07.024657-0300 Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null) com.apple.networkextension d
3
0
568
Nov ’24
Reply to Outgoing SSL connections fail on macOS 15, work fine on earlier versions
The system applies the same code signing and library validation checks regardless of whether you import the library or load the library dynamically. I agree with Etresoft that importing the library is the better option, but if you can’t change that then it’s not a showstopper. As to why LLDB is hanging, I don’t have an easy answer to that. I suspect it’s some sort of code signing or library validation issue. I’m disinclined to chase that because: LLDB isn’t a great tool for debugging code signing and library validation issues. It has enough on its plate being a debugger. Once you work out what’s going wrong with the library loading, it’s likely that LLDB will just start working again. Anyway, just to get us on a firm footing, I decide to run a test: On macOS 14.7.1 using Xcode 16.1, I created a new macOS app project. I downloaded the disk image from your first post and extracted the OpenSSL libraries. I modified them to be rpath-relative, per the docs I referenced above. I’ve put the exact commands at the end
Nov ’24
Pkg installation package uploaded to macstore email prompt ITMS-90296
Project Background: I developed a Mac project using Electron and VSCode Successfully uploaded the packaged pkg using Transporter, However, I will receive an email informing me that there are some issues with the project: ITMS-90296: App sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' Here is my packaging process: Generate an app using the electron packager tool Sign the app using @ electron osx sign (version
Replies
2
Boosts
0
Views
693
Activity
Nov ’24
Reply to errSecInternalComponent when trying to codesign an app through SSH
Ok, found a solution after 10 hours. When running standalone multiple SSH commands the unlock-keychain doesn't stick between commands, running: ssh ${REMOTE_SERVER} security unlock-keychain -p /Users//Library/Keychains/login.keychain-db && codesign -vvv --deep --force --verify --verbose --timestamp --options runtime --sign Developer ID Application: /tmp/$BUILD_ID/ui-app/.app Fixed it. Good luck :)
Replies
Boosts
Views
Activity
Nov ’24
errSecInternalComponent when trying to codesign an app through SSH
Hi, I'm trying to ssh into another machine, copy an app into that machine and codesign it using my Dev ID Application certificate, then copy it back to my original machine. I'm getting the errSecInternalComponent error when running codesign. This is the bash script I'm running: ssh ${REMOTE_SERVER} security -v unlock-keychain -p /Users//Library/keychains/login.keychain-db ssh ${REMOTE_SERVER} codesign -vvv --deep --force --verify --verbose --timestamp --options runtime --sign Developer ID Application: /tmp/$BUILD_ID/ui-app/.app ssh ${REMOTE_SERVER} codesign -dv --verbose=4 /tmp/$BUILD_ID/ui-app/.app I've tried to follow all the available info found online, managed to sign it successfully through the machine's UI, set the ACL of the private key to ALLOW ALL, restarted the keychain service, tried with the system keychain, approved all pop ups through the UI. Still with no luck through the SSH session. Any help would be greatly appreciated. Thanks!
Replies
2
Boosts
0
Views
586
Activity
Nov ’24
Pkg installation package uploaded to macstore email prompt ITMS-90296
Hello! I encountered an issue while packaging and uploading the project to the Mac store. I received an email stating: ITMS-90296: App Sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. Though you are not required to fix the following issues, we wanted to make you aware of them: ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight
Replies
18
Boosts
0
Views
1.8k
Activity
Nov ’24
Gatekeeper scans app before it finishes copying
Hi all, I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because it's damaged, even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app. I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done? I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation. Maybe there's a more elegant way? Thanks!
Replies
3
Boosts
0
Views
630
Activity
Nov ’24
Reply to Codesign dylib/framework with entitlements
[quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] Is it correct to codesign dylib/framewoks with entitlements? [/quote] No. It’s never correct to do that. Entitlements are only useful when applied to a main executable and can cause problems when applied to library code. [quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] Is this even allowed? [/quote] Depends on what you mean by “allowed”. It never does anything useful. It won’t be caught by either App Store Connect or notarisation. In most cases it’s benign. In some specific cases it will cause your program to be blocked by the trusted execution system. [quote='768184021, nangalvivek, /thread/768184, /profile/nangalvivek'] I know of at least one app that has passed notarization checks as well. [/quote] The goal of the notary service is for software to be “checked by Apple for malicious components”. It doesn’t audit your program for correctness, except as necessary to perform that goal. You can notarise a progr
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
Boosts
Views
Activity
Nov ’24
Reply to iOS 18 启动崩溃 main_executable_path_missing
In addition,app recently encountered a dyld crash similar to this crash on iOS15.5, which looks somewhat similar to the current crash. Not sure if it's the same, but it looks similar.See if it helps the analysis.I have a file bug,number is FB15719846 (iOS 15.5 dyld Crash),hope it helps.Thanks. Hardware Model: iPhone14,5 Process: XxxxxxXXX [265] Path: /private/var/containers/Bundle/Application/DAC8B886-80BB-48DB-916D-DBB854B69DFD/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.3 (81300) AppStoreTools: 15F31e AppVariant: 1:iPhone14,5:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [409] Date/Time: 2024-08-20 11:59:31.9614 +0800 Launch Time: 2024-08-20 11:37:02.3165 +0800 OS Version: iPhone OS 15.5 (19F77) Release Type: User Baseband Version: 1.61.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGKILL - CODESIGNING) Exception Subtype: UNKNOWN_0x32 at 0x00000001048d0000 Exception Codes: 0x0000000000000032, 0x00
Replies
Boosts
Views
Activity
Nov ’24
Codesign dylib/framework with entitlements
Is it correct to codesign dylib/framewoks with entitlements? My understanding is that only executables need to have the entitlement and the dylibs loaded in that process will automatically inherit those entitlements. However, I am seeing a lot of scripts on the internet that are signing dylibs as well with entitlements. For eg - # sign *.dylibs find $APP_BUNDLE -type f -name *.dylib -exec codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements $ENTITLEMENTS_FILE --sign $SIGNING_IDENTITY {} ; Is this even allowed? I know of at least one app that has passed notarization checks as well. If allowed, can a dylib have more entitlements than the process that loaded it?
Replies
2
Boosts
0
Views
1k
Activity
Nov ’24
Reply to "How to" for dext distribution
It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now. FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere else. First, I had changed the bundle ID of my dext to what it should be, after learning that the bundle ID ought to be an extension of the owning application's bundle ID. This is common practice and what Xcode does by default, but I don't believe the system actually requires it, as it needlessly restricts/complicates what's possible without any real benefit. It's been
Replies
Boosts
Views
Activity
Nov ’24
Reply to Xcode Project with Framework - Library not loaded - mapping process and mapped file have different Team IDs
I found this topic while trying to solve pretty much the same issue in my project, and since I've found a solution, I was thinking to share it in case it would help someone else in the same situation. Turns out the framework in the build folder is not signed, so it couldn't be loaded properly. At the same time the framework located in the resulted application bundle is signed properly, but it was not used for some reason. You can check the signature of the framework with codesign -d -r - Shared.framework command. I was able to solve the issue by adding following properties to the build settings, hope it will help someone LD_RUNPATH_SEARCH_PATHS = @executable_path/Frameworks LD_RUNPATH_SEARCH_PATHS[sdk=macosx*] = @executable_path/../Frameworks Essentially it loads frameworks from the expected location for the iOS build and the other location for the macOS build (the bundle structure is different depending on the destination).
Replies
Boosts
Views
Activity
Nov ’24
Reply to Unable to Write Files Within App Bundle After Codesigning and Notarization
[quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Are there any restrictions regarding this? [/quote] Yes. [quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Is there a way to bypass these restrictions? [/quote] No. App bundles are read-only by design. This isn’t a new requirement [1], but recent changes in macOS’s trusted execution system mean that it’s more important to follow the rules. To quote Embedding nonstandard code structures in a bundle: A bundle is a read-only structure. All Apple platforms except the Mac enforce this requirement at runtime. On iOS, for example, any attempt to modify your app’s bundle at runtime will fail with an error. The Mac may or may not enforce this requirement at runtime, depending on the context, but modifying your app’s bundle isn’t supported because it breaks the seal on the app’s code signature. So your current goal, having the app modify itself, is unsupported, likely to cause problems today, and even more likely to cause problems i
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’24
Unable to Write Files Within App Bundle After Codesigning and Notarization
Codesigned and notarized app cannot directly write files inside the app bundle (neither in my.app/Contents/Resources/ nor my.app/Contents/MacOS/). Are there any restrictions regarding this? Is there a way to bypass these restrictions? Here is the situation I encountered: The main app contains several sub-apps and sub-executables. When the main app calls the sub-apps or sub-executables, it can write files within the app bundle, but when executed directly, it cannot write files. The app is usually opened using the GUI, and when using the command line, neither the main app nor the sub-apps/sub-executables can write files within the app bundle. My codesigning environment is: Sonoma 14.0 on mac mini M1. I manually sign the app directly using the codesign command in CI instead of using Xcode. The process will traverse all of the files and sub-apps in the app folder and sign them from the deepest paths to the shallowest paths. I also tried applying this process to other applications, but a
Replies
3
Boosts
0
Views
825
Activity
Nov ’24
Reply to Content Filter: sourceAppAuditToken empty only for Firefox
This is clearly a bug. There should always be an audit token because some process must’ve started the flow. The next time you see this, please trigger a sysdiagnose log as soon as you see it, and then file a bug with that log. And once your done, I’d appreciate you posting the bug number here, just for the record. If you’re doing this on a ‘victim’ machine then you should enable additional NE logging via the VPN (Network Extension) for macOS instructions on our Bug Reporting > Profiles and Logs page. If you’re doing this on a real machine, you can enable that extra logging, but please consider the privacy impact. [quote='767822021, terransw, /thread/767822, /profile/terransw'] Not sure if relevant, but codesign with -dv showed different flags in CodeDirectory when compared to chrome: [/quote] That’s definitely not relevant. Chrome is opting in to some additional security checks, but Firefox gets most of those anyway because it’s enabled the hardened runtime (shown as runtime in that output). If yo
Replies
Boosts
Views
Activity
Nov ’24
Content Filter: sourceAppAuditToken empty only for Firefox
Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token. Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid. Debugging: My logging shows audit token is empty for Firefox Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for: com.apple.networkextension debug 11:22:07.024588-0300 Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null) com.apple.networkextension debug 11:22:07.024657-0300 Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null) com.apple.networkextension d
Replies
3
Boosts
0
Views
568
Activity
Nov ’24
Reply to Outgoing SSL connections fail on macOS 15, work fine on earlier versions
The system applies the same code signing and library validation checks regardless of whether you import the library or load the library dynamically. I agree with Etresoft that importing the library is the better option, but if you can’t change that then it’s not a showstopper. As to why LLDB is hanging, I don’t have an easy answer to that. I suspect it’s some sort of code signing or library validation issue. I’m disinclined to chase that because: LLDB isn’t a great tool for debugging code signing and library validation issues. It has enough on its plate being a debugger. Once you work out what’s going wrong with the library loading, it’s likely that LLDB will just start working again. Anyway, just to get us on a firm footing, I decide to run a test: On macOS 14.7.1 using Xcode 16.1, I created a new macOS app project. I downloaded the disk image from your first post and extracted the OpenSSL libraries. I modified them to be rpath-relative, per the docs I referenced above. I’ve put the exact commands at the end
Replies
Boosts
Views
Activity
Nov ’24