I would like to add an app (STS.app, the SpringSource ToolSuite) to the list of trusted apps for a given password entry within my keychain. The list already contains some apps (svn, Eclipse.app) but I can't add the given STS.app. After I choose that file from the file dialog, the list remains unchanged. I can delete/add other apps, e.g. the mentioned Eclipse.app but not the STS.app. Both files have equal permissions, but STS.app contains the com.apple.quarantine extended attribute. I can manually remove this ext.attribute (why does it ever exists, and why it wasn't removed automatically after the first start after download them via Chrome ???) but the STS.app is still not able to set as trusted app in keychain after that. Any suggestion ?
Kind regards, Dominik
After experiencing the same problem, I created the keychain item manually and that fixed it for me.
Go to your Mac keychain, click the '+' at the bottom, and then enter your SVN URL, friendly name and password.
Related
Starting in MacOS Sierra, I've started to get this popup periodically from XCode, even after pressing 'Always Allow'.
I've tried deleting the "com.apple.dt.XcodeDeviceMonitor" item in Keychain. This regenerates the key, but doesn't fix the issue.
It's an open discussion topic on the Apple forums, but no one seems to have a solution.
Posting this solution for Xcode 8 because no one else has:
Open Keychain Access.
Search for XcodeDeviceMonitor.
Drag the item to the System Keychain on left.
Enter admin password.
That finally fixes it.
open [keychain access] > type "xcode" in the search area > double click [com.apple.dt.XcodeDeviceMonitor] > click [access control] > select the first option [allow all applications to access this item]
Don't forget to click Save Changes!
hope it helps.
The following worked for me (running macOS 10.12.1 and XCode 7.3).
Note that the problem with other solutions is that they operate on the (temporary) login keychain entry, which is removed when XCode quits, so a solution appears to be to create the entry in the System keychain instead.
I tried using Keychain Access to move the entry from the login to the System keychain but it failed with various obscure errors (e.g. "An error has occurred. Unable to add an item to the current keychain")
Instead, I used the security command to create a new entry in the System keychain that's (almost) identical to the temporary one.
The only difference is the password which I couldn't be bothered to extract (and I'm unsure whether it's important).
Open Terminal, paste and execute the following command (after suitable editing if XCode isn't in the normal location):
sudo security add-generic-password \
-s 'com.apple.dt.XcodeDeviceMonitor' \
-a session-token \
-p anyoldstring \
-T /Applications/Xcode.app \
-T /Applications/Xcode.app/Contents/Developer/Library/Xcode/Tools/XcodeDeviceMonitor \
/Library/Keychains/System.keychain
Disclaimer - my sole objective here was to prevent the annoying alert.
I've no idea whether this will break anything.
You're messing with the System keychain: what could possibly go wrong ?
I reported this to Apple as a bug and after several suggestions the same as some of those mentioned here that didn't work they came back with the following, which has worked:
"Sorry about the trouble. We’ll dig a bit more into this. In the mean time, if you don’t need the iCloud gauge, you can temporarily disable it by doing this:
Go to Terminal.app.
Type this in to enable an User Defaults
defaults write com.apple.dt.Xcode iCloudGaugeDisabled -bool YES
Relaunch Xcode "
This issue has popped up again for me this past fall. I think the issue may stem from the security hole that apple had where the root user account was left un password protected. I reset my password for the root user account (to the same password as it was previously). I didn't notice the relationship at the time, but after reading this support item, I suspected that this could be the issue.
https://support.apple.com/en-us/HT201609
I reset my password for the login keychain (again to the same password) following these steps and the issue has since gone away.
Hope this helps.
I want to access the Firefox Root Store under Windows (7) with Firefox 45.0.1. I found several sources that told me to navigate to C:\Users\{username}\AppData\Local\Mozilla\Firefox\Profiles\8ab3jkih.default\cert8.db.
Unfortunately I can't find cert8.db, although 8ab3jkih.default is present (and the only folder).
I tried accessing the DB with certutil, which works, but only gives me 4 certificates for -viewstore (should be about 150). Afterwards I tried accessing -getconfig and -databaselocations, but that just tells me that the system can't find the given file. I hoped to find the location of the database.
Yes, I already heard of NSS, but figured I should try it manually first, before working with it.
Is there anything wrong with my installation? Should I try to reinstall? What else can I do? My endgame btw is finding out whether a certain given certificate is a root certificate, so I just want to programmatically access the list of root certificates and compare them to the given cert.
First be sure you have correctly located your Firefox profile directory.
You can open the menu in Firefox (the three horizontal bars button), find the Help, then go to Troubleshooting information.... In this page, you can see the Profile directory button. Press it and there you go.
Or, another way to open this page, is to type in the direction bar:
about:support
I created a DMG .this has 640 and apache permissions. once i uploaded it to internet some extended attributes are getting added to it. Because of that when customer downloads it they are getting a pop up
"There may be a problem with this disk image. Are you sure you want to open it?
Opening this disk image may make your computer less secure or cause other problems."
I don't want quarantine attribute to be added to it.so what should i do to my dmg before uploading it to internet such that quarantine attribute will not be set.And also why this pop is not coming for other dmg's downloaded from net. I downloaded google chrome.dmg, for that quarantine attribute is not set.can any one help me out with better solution
Did you sign the entire DMG as well as the .app file? I believe this is a new requirement if you have additional files in the DMG besides the signed .app.
(Copied from my answer at Mac DMG oddity - signing and "damaged" applications)
In addition to signing the .app bundle:
codesign -f -s "Developer ID Application: Your Dev ID Here" -v "Your App.app"
you should also sign the created DMG as well:
codesign -f -s "Developer ID Application: Your Dev ID Here" -v YourProgram.dmg
I didn't put quotation marks around the dmg file path because it's less likely that you have spaces in the dmg name. If you do, don't forget to escape them on the command line, or wrap your file path in quotes.
I don't want quarantine attribute to be added to it.so what should i do to my dmg before uploading it to internet such that quarantine attribute will not be set.
Distribute it through the App Store or sign it with your Apple developer account.
And also why this pop is not coming for other dmg's downloaded from net.
The other DMGs are probably distributed through the App Store or signed it with an Apple developer account.
Here's the settings of interest:
The best you can do is distribute through the App Store (in Apple's opinion).
I settle on the App Store and Identified Developers. There's no difference between the two in my opinion - in both cases, I rely upon Apple to check the developer and binary. Where it comes from (App Store vs Internet) does not matter to me.
However, I trust some developers more than Apple's assertion. For example, I have more trust for the Wireshark folks than anything Apple has to say about an unknown developer. I would install Wireshark even if it was not signed (xattr -r -d "com.apple.quarantine" <app> to the rescue).
I don't think this is related to the extended attributes or quarantine at all. That error message indicates that the filesystem in the disk image is corrupt, probably because the image was damaged during uploading/downloading (see this previous SU question). Can you checksum the image before and after uploading & downloading it to see if it's been changed somewhere along the path? Also, using Disk Utility to verify the volume would be useful.
As far as quarantine is concerned: the quarantine attribute is added when the image (or any other file) is downloaded; there is nothing you can do to prevent this. If there were a way to avoid this, the bad guys would be using it on their malware to evade the quarantine security checks -- and Apple would consider this a bug, and fix it. Your customer can remove the quarantine after downloading the image, but this should not be necessary. (Although you may want to sign some/all of the files inside the image to comply with gatekeeper's restrictions.)
My Mac used as a developing machine was down a few days ago. It turned out an issue of the HDD. Unfortunately, I forgot to backup my private keys for iOS development and distribution. So, I can't debug or distribute my apps now. I find that the old driver is still readable as a mobile HDD, but I just can't start the system on it(I've tried all well-known tools to recover but none of them worked).
Is it possible to get my private keys back from that driver? If not, what can I do as remediation?
Thanks in advance!
Derek
I'm not an iOS developer, but I'm pretty sure the keys are handled the same was as for a Mac developer: stored in your keychain. If this is the case, and you can mount the old HD, you should be able to recover the old keychain pretty easily:
Mount the old HD, and navigate into your old home folder in the Finder.
Open the hidden Library folder by choosing File menu > Go to Folder, then entering "Library" in the dialog.
Inside the Library, open the Keychains subfolder.
Copy Login.keychain to your new HD. This would also be a really good time to make a backup copy somewhere else as well.
At this point, you have a couple of choices. You can either migrate the relevant entries from your old keychain to the one in your new account (which may be tricky, 'cause they may not be easy to spot among all the other things stored in your old keychain), or just replace your new account's keychain with the old one (which means any new passwords etc you've memorized since swapping HDs will be unavailable). For the first option:
Rename the old keychain (to something like Old Login.keychain), then double-click it to open it in Keychain Access.
Unlock the old keychain by selecting it in the sidebar, then clicking the padlock icon near the top and entering your old login password.
Select the relevant items (good luck finding them all!), and drag them over to your current "Login" keychain in the sidebar. Authenticate as requested.
For the second option:
Quit everything except the Finder.
Open your current user Library folder (the easiest way to do this is to hold the Option key, pull down the Go menu, and choose Library.
Rename the current Login.keychain to something else, then move the old Login.keychain into its place.
Log out and back in. If your old login password was different than your new one, you'll get an error unlocking the keychain with an option to fix it by entering the old login password.
I have another question dealing with app sandboxing. So I need access to the users' home directory and at the same time the app should be able to shut down the Mac. This requires to not using sandboxing.
My problem is that I don't know how to remove sandboxing and being able to submit the app to the Mac App Store. I think that the archives are sandboxed because I had turned it on once..
How to remove sandboxing from the archives properly?
Thanks for your help!
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
If I understand what you are asking correctly, you'll need to remove the entitlements.plist from your project and make sure that the Summary view of your target in Xcode has sandboxing turned off:
As Derek Wade pointed out, you can make an App like GarageBand X (which behaves obnoxiously with third party plugins like Amplitube due to Sandboxing) NOT run in a sandbox by editing the binary itself with a HEX editor like HexFiend. Look for:
<key>com.apple.security.app-sandbox</key>
Immediately following that bit you'll see the true tag, which as suggested I switched to 'fals' (no extra bytes) and now GarageBand will happily interact with third party VST plugins. Huzzah.
I found if you go into the .app package, under Contents/MacOS, there should be a binary file that matches the name of your app. Copy that file to your desktop. Edit the desktop copy of the file with TextEdit. You should find within the file, the text representation (xml) of the Entitlements for the app. Find the Sandbox entitlement flag (usually set to <true/>) and change it to <false/>. You will have to unlock the file when editing. Save the file (located on the desktop). Rename the original file in the .app package (i.e. append .old to the filename). Copy the desktop file back to the .app Package location (you may have to authorize it). This should remove the sandboxing.
You cannot remove Sandbox if the user ran you application via Sandbox.
That's the whole point - don't you think ?