Post not yet marked as solved
What was the context / reason for disabling the DNS cache?
Post not yet marked as solved
Try FileManager.default.currentDirectoryPath for current working directory (CWD) or Bundle.main.bundlePath for execution path.
Post not yet marked as solved
Not sure if you can disable the DNS cache without disabling DNS completely.
To stop and continue queries try sudo killall -STOP mDNSResponder and sudo killall -CONT mDNSResponder. Also not sure what layers this affects and what they might cache.
You can still flush the DNS cache easily using sudo killall -HUP mDNSResponder so repeated calls might appear like a disabled cache. https://support.apple.com/en-us/HT202516
Use dns-sd -q apple.com to verify this:
dns-sd -Q apple.com
DATE: ---Tue 19 Jul 2022---
15:20:11.663 ...STARTING...
Timestamp A/R Flags if Name Type Class Rdata
15:20:11.664 Add 40000002 0 apple.com. Addr IN 17.253.144.10
15:20:14.156 Rmv 0 0 apple.com. Addr IN 17.253.144.10
15:20:14.166 Add 2 0 apple.com. Addr IN 17.253.144.10
Some historical commands are now deprecated with SIP and for security.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: Operation not permitted while System Integrity Protection is engaged
man mDNSResponder
sudo killall -INFO mDNSResponder
Sending SIGINFO to mDNSResponder daemon is deprecated. To trigger state dump, please use 'dns-sd -O', enter 'dns-sd -h' for more information
sudo dns-sd -O
XPC service returns error, description: State dump is only enabled in internal builds
Which macOS and Xcode versions?
Xcode managed certificates are recommended for initial setup which uses the default login keychain (see https://developer.apple.com/forums/thread/709545?answerId=719589022#719589022)
Try opening the p12 using the Keychain Access app, which will import to the default login keychain then right click on the certificate > Evaluate "Developer ID Application: Name (Team)" for Code Signing.
You can also get info on the certificate to confirm it is valid for code signing by checking the extensions for something like this:
Extension Key Usage ( 2.5.29.15 )
Critical YES
Usage Digital Signature
Extension Basic Constraints ( 2.5.29.19 )
Critical YES
Certificate Authority NO
Extension Extended Key Usage ( 2.5.29.37 )
Critical YES
Purpose #1 Code Signing ( 1.3.6.1.5.5.7.3.3 )
If it is not valid for code signing then export again using Keychain Access.
within the system area
Are you trying to share an identity for both users via a single entry in the system keychain?
Try importing into each user login keychain.
Post not yet marked as solved
Please mark my second reply as the correct answer to close this topic: https://developer.apple.com/forums/thread/709545?answerId=719589022#719589022
Post not yet marked as solved
Which method did you use?
Updating macOS should install the Apple root certificates then use Xcode managed certificates for your Apple Development certificate.
That WWDR may actually be the Apple Inc. Root (not G3).
Shows in System Settings > Desktop & Dock under Stage Manager on my macOS 13.0 Ventura Beta 3 (22A5295h) installs.
Do you have multiple browsers installed?
Post not yet marked as solved
So that looks like you are missing the entire chain of intermediate and root certificates probably because you are on outdated macOS 12.3 and haven't used Xcode managed certificates which will usually install everything you need.
Ideally you want to be on the latest macOS release which includes the latest root certificates in System Roots AND highly recommend you use Xcode managed certificates (Xcode > Preferences > Account tab > Manage Certificates) to download and install your Developer ID certificate even if you are not using Xcode automatic signing (or using a third party build system).
If you do need to install manually then based on your expiry, you will probably need to install the following from https://www.apple.com/certificateauthority/:
Login keychain: Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC)
System Root: Apple Root CA - G2 Root
Manual installation and trust of root certificates is not recommended. Update your macOS and use Xcode managed certificates.
Post not yet marked as solved
Not an expert but Developer ID certs do not use WWDR intermediate certificates (those are for Apple Development).
In Keychain Access:
right click your Developer ID Application: Name (Team) certificate
select Evaluate "Developer ID Application: Name (Team)"
click Continue
click Show Certificate
First click of Show Certificate (without changing selection) should show a chain like:
Apple Root CA
Developer ID Certification Authority
Developer ID Application: Name (Team)
Depending on issue date, Developer ID Certification Authority would be one of:
Developer ID - G1 (Expiring 02/01/2027 22:12:15 UTC)
Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC)
For that WWDR it looks like you are missing Apple Root CA - G3 Root in your system roots.
@eskimo any update from your discussion?
Post not yet marked as solved
Check this thread on using build configuration files to externalise versions for easier updating by your own scripts: https://developer.apple.com/forums/thread/709065?answerId=718911022#718911022
Post not yet marked as solved
Customizing the notarization workflow: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow
Thanks so much for your detailed response. I wondered whether it was supposed to inherit, but couldn't get that to work. (I wasn't advanced enough to understand the "levels" setting or to look at that). It turns out the Apple build template overrode the default and the way to reset a default is to highlight the row and hit delete. (Don't try leaving it blank, or setting it back how you found it after the build template set it) Next task is explore your build configuration advice. @obscurebug
This was something I looked at again recently. My last post about versions and auto incrementing build numbers in Xcode was 2008-12 for Leopard / Xcode 3.x!
Build configuration files are a lot cleaner in source commits (vs project.pbxproj) especially if they are high change like build numbers. You can also include other xcconfig files eg #include "versions.xcconfig" for further separation. Not modifying project.pbxproj provides more flexibility for auto incrementing build numbers in a Run Script Phase.
MARKETING_VERSION (CFBundleShortVersionString in Info.plist): https://developer.apple.com/documentation/xcode/build-settings-reference#Marketing-Version
CURRENT_PROJECT_VERSION (CFBundleVersion in Info.plist): https://developer.apple.com/documentation/xcode/build-settings-reference#Current-Project-Version
CFBundleShortVersionString: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring
CFBundleVersion: https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion (important for App Store updates)
Targets inherit from project settings so you could just set the CURRENT_PROJECT_VERSION and MARKETING_VERSION in the project, delete the target specific build settings and each target will then use the project settings.
Customised / Levels at the top left of build settings helps to see what is customised or inherited in each target.
You can also use build configuration files to specify build settings for the project or specific targets / configurations which are often easier for scripts to update, avoiding any parsing of project.pbxproj files: https://developer.apple.com/documentation/xcode/adding-a-build-configuration-file-to-your-project
eg setting the following project.xcconfig for all configurations (and removing CURRENT_PROJECT_VERSION / MARKETING_VERSION from the project / target build settings) will use the xconfig versions for all targets:
project.xcconfig
CURRENT_PROJECT_VERSION = 1.0.0
MARKETING_VERSION = 1.0
You can also reference custom build settings just like any other build setting. eg $(MY_CUSTOM_BUILD_SETTING)
One of my projects uses xcconfig to manage custom TOOLS_OWNED / HELPER_AUTHORISED_CLIENTS (SMPrivilegedExecutables / SMAuthorizedClients) build settings for multiple targets and debug / release / distribution configurations as an alternative to SMJobBlessUtil-python3.py updating Info.plist files.
