Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 months ago.
Improve this question
I installed macOS v11 (Big Sur) yesterday and since then I am not able to run some old application. This is the message I get:
You do not have permission to open the application
I think this application is from an unknown developer.
I tried different methods that were working in macOS v10.15 (Catalina) like:
spctl --master-disable
Or I tried also to disable SIP and AMFI.
I've also tried:
sudo xattr -rd com.apple.quarantine /Applications/my_app.app
If I run the application from the terminal, this is the text version of the error I get:
The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2508, NSUnderlyingError=0x7fcb24c13ec0 {Error Domain=RBSRequestErrorDomain Code=5 "Launched process exited during launch." UserInfo={NSLocalizedFailureReason=Launched process exited during launch.}}}
Also tried to disable encryption and run:
csrutil authenticated-root disable
This is the error window:
I had this problem with the error "Termination Reason: Namespace CODESIGNING, Code 0x1" and I managed to open the application after I signed it again on that machine, with the command:
codesign --force --deep --sign - /Applications/AppName.app
No other solution worked for me.
It seems to be a permissions issue on one of the files deep in the .app that you moved to the applications directory.
Open Terminal or iTerm and type "chmod -R 755 " and drag the .app into the window, which will bring the full path into Terminal or iTerm.
It will look like this:
chmod -R 755 Path\ to\ app\ file.app
Press return
Then, you can open the app file normally, but it will fail because gatekeeper won't be able to verify the file. From there, go into your "Security and Privacy" in "System Preferences" and then click to allow the app to open.
The problem in my case it was related to a Big Sur problem where UPX compressed binaries are not recognised properly, so they were not executed with a permission error.
There is some more information here: UPX compressed application fails to start on latest macOS release: Big Sur 11.01 #424
So the solution is to unpack the binary with UPX and run it normally.
Install upx with Homebrew (executable brew):
brew install upx
Now run this command:
sudo upx -d /Applications/my_app.app/Contents/MacOS/my_app
(Please note you have to specify the full binary path.)
You should use the path of your binary instead of "/Applications/my_app.app/Contents/MacOS/my_app"
Then run the application normally.
I found a solution:
You need to resign the app,
(install Xcode tools, if necessary):
xcode-select --install
sudo codesign --force --deep --sign - /Applications/YourAppName.app
Move the app to quarantine:
sudo xattr -d -r com.apple.quarantine /Applications/YourAppName.app
Go to /Applications/YourAppName.app/Contents/MacOs and make the file inside executable:
sudo chmod +x Script_name
That worked for me and the app launched.
This answer will only apply to a specific set of applications
I had this issue with a universal binary (Terminal) that I duplicated and explicitly set in the info "Open using Rosetta" to run x86 tools like Homebrew. After updating to 11.0.1 from 11.0.0, the x86 version of the terminal stopped working with the above error.
I simply had to delete the duplicate, created another duplicate of the terminal and enabled Rosetta again.
First figure out that your application signature is valid:
From Apple's official website:
All apps in the App Store are signed by Apple to ensure they have not been
misused or tampered with. Apple signs any app that comes with Apple
devices.
To check this out, you can type the following in your terminal (the path of Folx.app is just for an example and you should replace it with your desired app):
pkgutil --check-signature /Applications/Folx.app
if you get an "invalid signature" responce, something like this:
Then your app maybe was installed in some hacky way! And now your easiest approach is to uninstall the app and reinstall it again.
Otherwise, you will have plenty of hard time to enjoy (đ) with that app, Xcode, and signature stuff...
You have to run SUDO xattr -d com.apple.quarantine <app>. It's important that you don't forget sudo or it won't work.
This is the only solution that worked in my case.
Download macOS-GateKeeper-Helper.
Open GateKeeper_Helper.command by double-clicking on it (if it says untrusted developer, go ahead and run it from Settings - Security & Privacy - General - Open Anyway)
Select Option 4 (Remove app from GateKeeper quarantine)
Drag and drop the app file from the Applications folder, hit the Return key, and enter your password
You will see a message like âApp removed from quarantineâ. Thatâs it. Try to open the app as usual.
If you are uploading an Xcode app to GitHub releases, make sure to compress it first on your computer, don't let GitHub compress it.
For my team, this turned out to be a problem with Git adding CRLF to the Entitlements.plist file.
Once I fixed the .gitattributes file to only use LF with p-list files, I built a new app and had it codesigned and it worked--no aborts. I also had to make sure Jenkins wiped the workspace since it didn't seem to fix the file at first.
I encountered this issue when sending to a colleague for testing a Mac app that I developed. He tried some of the suggestions on this forum, but they didn't seem to work (and we're both on Intel, so the Rosetta tips didn't apply).
What ultimately worked for me was creating a blank disk image, and then adding the .app file to the image and then sending him the disk image. It seems like the problem comes up when the .app file is compressed, and adding the file to a disk image first seems to help prevent the issue.
I'm trying to install the omnetpp simulator abut I was not able to use its graphic interface. To run it properly I have to install Qt5 which I did through homebrew. My Qt version is 5.15.0 and my MacOS is Catalina (10.15.5 (19F101)).
When running the ./configure command to install omnetpp, I got the following error:
âqmakeâ cannot be opened because the developer cannot be verified.
In summary I had problems with the omnetpp when trying to run the graphic interface Qt, then I've installed Qt5 and now I get an error telling me that qmake cannot be verified.
Thanks,
The problem is that this will come many times... It has something to do with the new security settings for MacOS Catalina.
I found another work-around, which worked very well for me. Go to Systems Preferences -> Security and Privacy -> Privacy. Scroll down the left menu to Developer Tools and allow Terminal to run software locally (tick the box).
I was able to circumvent this problem by opening System Preferences, Security & Privacy, General, and then allowing the file to be executed. When I ran make again the Qmake command ran without any warnings or windows popping up.
According to Apple's website, you need to find qmake in the Finder, CTRL+click on it and press "Open". After that, qmake will be marked as an authorized app and you can run ./configure again.
I am a Windows user and could find the official Apple support page (https://support.apple.com/de-de/guide/mac-help/mh40616/mac) within a minute of googling, by the way.
You can run the following command to "un-quarantine" your binary (assuming its path is /usr/bin/qmake):
xattr -w com.apple.quarantine "00c1;$(xattr -p com.apple.quarantine /usr/bin/qmake | cut -d";" -f2-4)" /usr/bin/qmake
I develop a Mac app with Qt5, so outside Xcode. I want GateKeeper to allow my app to run on clients' computers rather than issuing the "Can't be opened because the identity of the developer cannot be confirmed" warning.
I have successfully digitally signed the app but GateKeeper still comes with this complaint. I have an Apple developer certificate (I am the Team Agent) and my keychain says it is valid. I also have installed two Apple root certificates.
I use the command line utility codesign to digitally sign all the binaries inside the app folder and in addition I digitally sign the app folder itself. In all cases the response of codesign is informative and displays no error. With codesign I can check that indeed all the binaries are signed, running
$ codesign --verify --deep --verbose=2 MyApp.app
shows that all binaries are validated. And in addition it reports:
MyApp.app: valid on disk
MyApp.app: satisfies its Designated Requirement
Running:
$ codesign -v --verbose=4 --display MyApp.app
gives
Executable=/Users/xxx/trunk/yyy/deploy/release/MyApp.app/Contents/MacOS/MyApp
Identifier=aaaa.MyApp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=12461 flags=0x0(none) hashes=616+3 location=embedded
Hash type=sha1 size=20
CDHash=d1c12c783dac0e8d9a2b749fb896b11558cec8b6
Signature size=8532
Authority=Developer ID Application: XXXXX
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 jul. 2015 12;04:40
Info.plist entries=8
TeamIdentifier=YYYYY
Sealed Resources version=2 rules=12 files=10
Internal requirements count=1 size=180
which seems OK.
Running
$ spctl -a -t exec -vv MyApp.app
on all binaries gives as result
MyApp.app: accepted
source=Developer ID
origin=Developer ID Application: XXXX
which also seems OK
Running the XCode command line tool check-signature
on the app or on the binaries inside the app folder:
$ ./check-signature /Users/xxx/trunk/yyy/release/MyApp.app
gives as result
(c) 2014 Apple Inc. All rights reserved.
YES
which in all cases is the desired result.
But GateKeeper still does not accept the app and complains about the fact that the developer cannot be confirmed.
[added by author on Friday July 17, 2015]
I think I have found the problem. I do not know whether it is a feature or an OSX bug. I was helped a lot by stackoverflow question 19551298.
Whenever a file is downloaded from the internet it gets an extended file attribute com.apple.quarantine associated with it. When double-clicking on this downloaded file in Finder, GateKeeper has two possibilities:
When the file is not signed it issues the "Unidentified developer etc" message
When the file is digitally signed it issues the "Developer cannot be confirmed etc" message
In both cases the MessageBox has only one button, an OK button. When this button is clicked nothing happens, apart from the MessageBox closing.
If the extended attribute is deleted (xattr -d) the applications runs, signed or not.
The behavior is different when the applications is started by right-mouse-button-clicking in Finder on the app and then click on the "open" menu action. Again one of the two messageboxes is shown, but now with an extra button to allow the user to open the app anyway. Again the only difference between signed and not signed is the "Unidentified" or the "Not confirmed" message. I do not expect my customers to be able to tell the differende. As a result signing the app is an exercise in futility.
On the basis of the Apple Support Documentation I expected another, much nicer behavior of GateKeeper when double clicking a downloaded app (perhaps the documentation is outdated, or I misread it):
if the app is signed GateKeeper should show a MessageBox with "Downloaded from the internet etc" and a button with "Proceed anyway?"
if the app is not signed a MessageBox with a single OK button and a text "Unidentified developer etc.."
Sorry for answering my own question, but I see no other way as editing the original question would lead to spaghetti text.
I finally solved my problem. First the credit: (i) The answer to my other stackoverflow question was very useful and (ii) I got very good (paid) advice from an official Apple developer, by filing a so-called Technical Support Incident (TSI).
On the basis of all this I am now able to give here a very concise recipe of how getting your Mac app successfully treated by GateKeeper. After detailing the recipe I will show what my original mistake was.
Goal: After having developed a Mac app outside Xcode to have GateKeeper issuing the warning "Downloaded from the Internet ..." with three buttons, one of which is "open".
Failure: When GateKeeper issues a warning with either the text ".. unidentified developer.." or the text ".. unconfirmed developer .. " with - in both cases - a messagebox with a single OK button.
Getting your app GateKeeper-ready involves three steps:
Make your app standalone with no unacceptable external dependencies. The only acceptable external dependences are system libraries. All other dependencies should have been copied to your MyApp.app folder. GateKeeper rejects any app that has non-system external dependencies
Binaries should not be located at illegal positions inside the MyApp.app folder. Libraries go into MyApp/Contents/Frameworks and the executable goes into MyApp/Contents/MacOS
All binaries inside MyApp should be digitally signed. Then the MyApp.app folder should be signed. For this signing an Apple "Developer ID Application ..." certificate is necessary
Our recipe is automatic. All the work is done by one script. In case of Qt Creator we use a qmake script where we access the system shell through the $$system command. When using either of the (Xcode) system commands codesign, spctl or check-signature we assume you have redirected stderr to stdout as outlined in answer to question . Otherwise you will not be able to catch the system response when running these utilities. In the following we will not explicitly show this redirection.
HERE IS OUR RECIPE
A. Making the app stand-alone:
copy (with a script) all the needed binaries to the MyApp.folder
run (with a script) install_name_tool -change and install_name_tool -id such that all dependences inside the app are of the relative type #executable_path/../MacOS.. or #executable_path/../Frameworks
run (with a script) otool -L on all binaries inside the MyApp.app folder and flag any illegal dependence, like "#rpath..." or absolute file paths not being system paths. Note that otool -L is not guaranteed to find all dependencies. Plugins are often beyond the horizon of otool. That is why you need the next check.
start a terminal at the location "MyApp.app/Contents/MacOS". Run export DYLD_PRINT_LIBRARIES=1. Then run inside the same terminal window ./MyApp. Your terminal will fill up with over hundred loaded libraries. Check this list again for forbidden libraries (libraries present on your computer, but not on the computer of your customers).
proof of the pudding is in the eating. We use the MacInCloud virtual machines and check whether or not our app runs there. Alternative solution could be the Mac of a relative who is not a developer. Or you could also create a new user ("test") on your own Mac and copy the app to its Download (or Desktop folder, or ...). In the latter case you must temporarily rename the root folder of your IDE as otherwise the user "test" will find the missing binaries there.
B Signing the app
Signing: With our script we run codesign --force --verify --verbose --sign \"Developer ID Application: ....\" \"/path/to/binary\" on all the binaries in the app and then on the app folder itself. In each case the system response is caught. It should contain in each case the string "signed Mach-O thin".
Verification: Run (with a script) command codesign --verify --verbose \"/path/to/binary\" on each binary in your app and on the app itself and catch the system response. It should in each case contain the strings "valid on disk" and "satisfies its Designated Requirement".
GateKeeper check: Run (with a script) spctl -a -t exec -vv /path/to/binary\" on each binary and on the app folder itself. The system response is caught. It should contain in all cases the string "accepted source".
check-signature: Run (with a script) check-signature \"/path/to/banary\" on each binary and on the app folder itself. The system response is caught. It should contain the string "YES" in each case.
C External check
zip your app into a single zip file. Upload to one of your cloud servers
GateKeepers keeps a long list (typically hundreds of items) of exceptions on its general gate-keeper role. Your app must not be in that list if you want to test GateKeeper. Rather than editing this list a much simpler trick is creating a new user on your Mac. Log in to that user and download the zip file from the Internet cloud server. Finder will automatically uncompress it. Click on it. If GateKeeper tells you that it can open the application but it warns you at the same time that it is downloaded from the Internet, it is time to grab a (white) beer.
Here the desired GateKeeper warning:
My mistake
I did much of the installing and signing without explicitly checking the result for each binary. After that I would use otool -L on a number of binaries but not on all. I missed the fact that upgrading to Qt 5.5 from an earlier Qt version the binary libqminimal.dylib has acquired an extra dependency, viz.: QtDBus. I had not noticed it, but GateKeeper did.
Qt developers might wonder why we not just use macdeployqt for deploying Qt application on a Mac. In the first place we do not like not to use ill-documented black-box utilities. On Internet fora there are quite a number of people reporting issues with macdeployqt. In addition the Qt libraries can have different install locations (as reported by otool-L) when comparing different Qt versions. When we have a new Qt version our script will immediately start to yell about forbidden dependencies. In this way we get information about what has changed in this new version.
adlag's question and self-answer was invaluable in helping me overcome the same issue. However, as good as his recipe is, some statements are not quite right, so I'd like to offer a few additional points.
It's not necessary to replace #rpath entries in your binaries and dynamic libraries with #executable_path statements. #rpath statements are fine so long as the actual rpath entries embedded in the binaries are not absolute. You can find plenty of valid Qt app bundles that use rpath. You can make it work doing what adlag said, but you may be making work for yourself.
See jil's comment above for how to use otool -l $file | grep -A2 LC_RPATH and install_name_tool -delete_rpath $path $file to inspect and remove the embedded paths in your binaries and libraries
See https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207 for a clear explanation of why GateKeeper complains about paths in your binaries, and how you can see the specific complaint in syslog.
If you have a problem with absolute paths, you should first try to fix your build, rather than use install_name_tool after the fact.
If you're using cmake, this is likely helpful: https://cmake.org/Wiki/CMake_RPATH_handling#Mac_OS_X_and_the_RPATH
Don't run spctl -a -t exec -vv /path/to/binary on dylib files. You will get errors about the resource envelope. This is expected, and not a problem.
In my experience, macdeployqt works fine. I solved the problem by changing my build, such that the absolute paths did not get into the offending dylib file (libquazip). I still used install_name_tool to remove the absolute paths to the Qt installation. I then used macdeployqt to create the bundle, sign the bundle and create the DMG file.
My two bits:
To really verify codesigning, I had to either upload my DMG to a
server and download it using a browser or set the quarantine attribute manually:
APP_PATH="Any.app"
xattr -w com.apple.quarantine '0081;5a37dc6a;Google Chrome;F15F7E1C-F894-4B7D-91B4-E110D11C4858' "$APP_PATH"
xattr -l "$APP_PATH" # You should see the quarantine attribute here
open "$APP_PATH"
If your app is correctly signed, you should see a system dialog with
an "Open" button.
I found the value of the quarantine attribute by looking at another
.app downloaded from the internet. I don't know what the value
means.
I don't really understand why the spctl command says "accepted" even
if the Gatekeeper service denies opening the app.
I had the "unidentified developer" message box because my Qt frameworks were referenced as "#rpath/QtCore.framework". Changing it to "#application_path/../Frameworks/QtCore.framework" using the install_name_tool fixed the issue in my app.
Figured out the problem after lot of tries.
In my case:
The Pop Message - damaged application came due to libraries were missing.
I Had created .app file using QT.
To generate dmg i was using deploymacqt command tool.
deploymacqt tool creates dynamic libraries inside .app, so basically if we codesign before creating dmg, this alter will manipulate code sign.
So the proper fix is.
# Create dmg using
deploymacqt <yourapp.app> -dmg
# Open resulted dmg file, copy <yourapp.app> to different folder(let's say /Documents/<yourapp.app>)
# Codesign the /Documents/<yourapp.app> using
codesign --deep --force --verify --verbose --sign "Developer ID Application: <developerid>" <yourapp.app>
# Verify using
codesign --verify --verbose=4 <yourapp.app>
* you should see something like this
<yourapp.app>: valid on disk
<yourapp.app>: satisfies its Designated Requirement
# Now create again the dmg file using dropdmg(https://c-command.com/dropdmg/) application, download, install dropdmg. set the cofiguration preferences with your developer id certificate in signing option.
# drag and drop <yourapp.app> to dropdmg app, wait for creation of dmg to complete. voila you have now successfully created dmg with proper developer id certification.
# verify resulted dmg again using
codesign --verify --verbose=4 <yourapp.dmg>
# you can also verify with gatekeeper
spctl -a -t exec -vv <yourapp.dmg>
once you are done with these, you will not see pop message saying app is damaged or broken or unidentified developer.
You need to verify all your rpath with command line otool -l of your executable and yours Frameworks. If you have a local rpath (ex: /user/name/Qt/) in your executable delete it (with this command install_name_tool -delete_rpath).
My app runs fine but gdb fails to debug it with the following error
(gdb) run
Starting program: /path/to/app
Unable to find Mach task port for process-id 83767: (os/kern) failure (0x5).
I am on OS X Lion. GDB version is
$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".
It works when I change to sudo gdb executableFileName! :)
In Snow Leopard and later Mac OS versions, it isn't enough to codesign the gdb executable.
You have to follow this guide to make it work: http://www.opensource.apple.com/source/lldb/lldb-69/docs/code-signing.txt
The guide explains how to do it for lldb, but the process is exactly the same for gdb.
You need to create a certificate and sign gdb:
Open application âKeychain Accessâ (/Applications/Utilities/Keychain Access.app)
Open menu /Keychain Access/Certificate Assistant/Create a Certificate...
Choose a name (gdb-cert in the example), set âIdentity Typeâ to âSelf Signed Rootâ, set âCertificate Typeâ to âCode Signingâ and select the âLet me override defaultsâ. Click âContinueâ.
You might want to extend the predefined 365 days period to 3650 days.
Click several times on âContinueâ until you get to the âSpecify a Location For The Certificateâ screen, then set âKeychain to Systemâ.
If you can't store the certificate in the âSystemâ keychain, create it in the âloginâ keychain, then export it. You can then import it into the âSystemâ keychain.
In keychains select âSystemâ, and you should find your new certificate. Use the context menu for the certificate, select âGet Infoâ, open the âTrustâ item, and set âCode Signingâ to âAlways Trustâ.
You must quit âKeychain Accessâ application in order to use the certificate and restart âtaskgatedâ service by killing the current running âtaskgatedâ process. Alternatively you can restart your computer.
Finally you can sign gdb:
sudo codesign -s gdb-cert /usr/local/bin/ggdb
sudo ggdb ./myprog
The problem is that you are not logged in as a root user (which you don't want). You need to create a certificate for gdb to be allowed access. Follow this tutorial and you should be good to go...
http://sourceware.org/gdb/wiki/BuildingOnDarwin
If all else fails, just use: sudo gdb executableFileName
This link had the clearest and most detailed step-by-step to make this error disappear for me.
In my case I had to have the key as a "System" key otherwise it did not work (which not every url mentions).
Also killing taskgated is a viable (and quicker) alternative to having to restart.
I also uninstalled MacPorts before I started this process and uninstalled the current gdb using brew uninstall gdb.
I needed this command to make it work on El Capitan:
sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/gdb-cert.cer
Here is a really useful guide which solved my problem(OSX 10.13.6).
Open Keychain Access
In the menu, open Keychain Access > Certificate Assistant > Create a certificate
Give it a name (e.g. gdbc)
Identity type: Self Signed Root
Certificate type: Code Signing
Check: let me override defaults
Continue until it prompts you for: "specify a location for..."
Set Keychain location to System
Create a certificate and close assistant.
Find the certificate in System keychains, right click it > get info (or just double click it)
Expand Trust, set Code signing to always trust
Restart taskgated in terminal: killall taskgated
Run codesign -fs gdbc /usr/local/bin/gdb in terminal: this asks for the root password
I followed this tutorial, and everything is OK.
On MacOSX lldb needs to be code signed. The Debug and Release builds are set to code sign using a code signing certificate named lldb_codesign.
If you don't have one yet you will need to:
- Launch /Applications/Utilities/Keychain Access.app
- In Keychain Access select the "login" keychain in the "Keychains"
list in the upper left hand corner of the window.
- Select the following menu item:
Keychain Access->Certificate Assistant->Create a Certificate...
- Set the following settings
Name = lldb_codesign
Identity Type = Self Signed Root
Certificate Type = Code Signing
- Click Continue
- Click Continue
- Click Done
- Click on the "My Certificates"
- Double click on your new lldb_codesign certificate
- Turn down the "Trust" disclosure triangle
Change:
When using this certificate: Always Trust
- Enter your login password to confirm and make it trusted
The next steps are necessary on SnowLeopard, but are probably because of a bug
how Keychain Access makes certificates.
- Option-drag the new lldb_codesign certificate from the login keychain to
the System keychain in the Keychains pane of the main Keychain Access window
to make a copy of this certificate in the System keychain. You'll have to
authorize a few more times, set it to be "Always trusted" when asked.
- Switch to the System keychain, and drag the copy of lldb_codesign you just
made there onto the desktop.
- Switch to Terminal, and run the following:
sudo security add-trust -d -r trustRoot -p basic -p codeSign -k /Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer
- Right click on the "lldb_codesign" certificate in the "System" keychain (NOT
"login", but the one in "System"), and select "Delete" to delete it from
the "System" keychain.
- Reboot
- Clean and rebuild lldb and you should be able to debug.
That should do it.
[Note: - lldb is used in mac as gdb.]
These instructions work for OSX High Sierra and avoid running gdb as root (yuck!). I recently updated from OSX 10.13.2 to 10.3.3. I think this is when gdb 8.0.1 (installed w/ homebrew) started failing for me.
I had difficulty with other people's instructions. After different instructions, everything was a mess. So I started a fresh. I more or less followed these instructions.
Clean the mess :
brew uninstall --force gdb # This deletes _all_ versions of gdb on the machine
In Applications -> Utilities -> Keychain Access, I deleted all previous gdb certificates and keys (be sure you know what you're doing here!). It's unclear if this is necessary, but since I'd buggered up trying to create those certificates and keys using other instructions I eliminated them anyways. I had keys and certificates in both login and system.
Now reinstall gdb.
brew install gdb
Within Keychain Access, go to menu Keychain Access-> Certificate Assistant -> Create a Certificate
Check "Let me override defaults" and set
Name : gdb-cert
Identity Type: Self Signed Root
Certificate Type : Code Signing
[X] Let me override defaults
On 1st Certificate Information page:
Serial Number : 1
Validity Period (days): 3650
On 2nd Certificate Information page, I left all fields blank except those already filled in.
On Key Pair Information page, I left the defaults
Key Size : 2048
Algorithm : RSA
On Key Usage Extension page, I left the defaults checked.
[X] Include Key Usage Extension
[X] This extension is critical
Capabilities:
[X] Signature
On Extended Key Usage Extension page, I left the defaults checked.
[X] Include Extended Key Usage Extension
[X] This extension is critical
Capabilities:
[X] Code Signing
On Basic Constraints Extension Page, nothing was checked (default).
On Subject Alternate Name Extension page, I left the default checked and didn't add anything else.
[X] Include Subject Alternate Name Extension
On Specify a Location for the certificate page, I set
Keychain: System
I clicked Create and was prompted for my password.
Back in the Keychain Access app, I went to System and right clicked on gdb-cert and under dropdown menu Trust, I changed all the fields to Always Trust.
Rebooted computer.
At the Terminal, I ran codesign -s gdb-cert /usr/local/bin/gdb. I entered my password when prompted.
At the Terminal, I ran echo "set startup-with-shell off" >> ~/.gdbinit
I ran gdb myprogram and then start within the gdb console. Here, I believe, it prompted for me for my password. After that, all subsequent runs, it did not prompt for my password.
This is a weird approach but it worked for me(MacOs HighSierra 10.13.3). Install CLion. It comes with gdb. Once run the gdb using Terminal. Copy the gdb program to your usr/local/bin/. No problem of signin, sudo etc.
Following the instructions here Codesign gdb on macOS seemed to resolve this issue, for me, on macOS High Sierra (10.13.3).
I have a XCode which builds and runs under XCode.
I would like to know if it is possible to debug it using a gdb I build under Mac OSX (gdb 7 to be specified). If yes, can you please tell me how can I do that?
Thank you.
gdb-7.0 reverse debugging currently can only work with two classes of targets:
1) a remote simulator/emulator/virtual-machine that supports going backwards, or
2) the built in "process record" target, which at present has only been ported to x86-linux, x86-64 linux, and moxie linux.
Well, now -- I take that back. I recently discovered that process record can work with any remote x86 target, so if you're connecting with your macintosh target via "target remote", you might just be able to do it!
There is an online tutorial for process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
More info about process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord
And about gdb reverse debugging here:
http://www.sourceware.org/gdb/wiki/ReverseDebug
So you want to use your own version of gdb to debug your executable? Easy!
Open Terminal, and do something like this:
$ cd <directory where Xcode project lives>
$ cd build/Debug (for example - depends on project configuration)
$ /usr/local/bin/my-gdb ./MyExecutable
Of course, specifying the actual path to your custom gdb version.
XCode's debugger is gdb (likely with Apple-specific modifications.) When you debug an application you can get to the gdb command line by opening the Console from the Run menu.
What requirements are imposed on your application that would require you to debug with your own version of gdb?