Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I've accepted this so many times that firewall should already remember it.

For example, I get it for Eclipse when starting my java programs in debugging mode ... sometimes this dialog is displayed only very shortly, like half second, and disappears. I also get it for iTunes (when I enable sharing my library), and other programs, even though I have them listed in Firewall preferences panel (adv. settings).

share|improve this question
    
What version of OSX are you using? –  Martín Marconcini Oct 18 '10 at 14:58
    
@Martin: added snow-leopard tag. I use latest and greatest 1.6.4. –  Peter Štibraný Oct 18 '10 at 15:19
    
The behavior is very odd to my knowledge. The firewall looks at the app signature to recognize it, so any change in the app, means it might no longer be recognized and thus will cause a new prompt. Leopard was more prone to this than 10.6, however it still happens from what you’re telling. –  Martín Marconcini Oct 18 '10 at 15:27
    
I used to see this all the time with VirtualBox on Snow Leopard. I'd love to hear an explanation for it as well. –  Ben Wyatt Oct 18 '10 at 15:32
    
Very annoying. I see the popup a couple of times per day while working in Eclipse. It only shows up for a sub-second or so. This happens on Mountain Lion with Eclipse Juno SR2. –  Gunnar Wagenknecht Jun 7 '13 at 15:19

3 Answers 3

up vote 2 down vote accepted

There are two options here:

  1. You can simply select "Allow All" in your firewall, or simply turn it off.
  2. You can remove the apps from the list, delete the plist file for those apps, run them, and then add them to the list. The plist is responsible for a lot of behaviors and I'm willing to bet either an upgrade to the OS or the app can cause the "link" to break.

About plist files... A plist is a special kind of text file that contains properties the application and other resources, typically the OS, use to retain and reuse information needed to run the application. plist is a file type and has many uses, typically storing user preferences, but, essentially, it is an XML file. You can look to see if there are any caches, which are typically plist files, for the applications in question in /Library/Caches and /System/Library/Caches. There is also one in ~/Library/Caches/ but bad things can happen when mucking around in there, so just leave it alone. The system goes into those folders for a wide variety of reasons, and I usually clean out the first two folders I listed completely about once a month.

share|improve this answer
    
Can you please explain what you mean by "delete the plist file for those apps"? –  Peter Štibraný Oct 18 '10 at 18:05
    
the plist files contain the application settings among other things (and it’s safe to delete them, but always make a copy just in case). Any Cocoa app must be programmed to re-create its own plist should the file “disappear”. The plist for apps are usually located in /Users/your_user/Library/Preferences. The files end with .plist extension and usually have names like: “com.company.appname.plist” e.g: com.adobe.Phosothop.plist . You can move them to your desktop and launch the application to “re-create” it. –  Martín Marconcini Oct 18 '10 at 21:36
    
Are the ~s in the file paths above referencing the current user's home folder or the root directory? –  todofixthis Feb 2 '12 at 17:55
    
By convention, macs have no root user so ~ implies a user home folder. / is of course the root directory –  bmike Feb 25 '12 at 0:22
    
Downvoted since this is not really an option in many cases. user465139's comment is more appropriate. Though still a security risk--it is at least less than allowing all apps in/out. –  sholsinger Sep 13 at 23:03

While RedYeti's link is useful, just to save a few clicks for others let me recap how to generate a code-signing cert and to use it for code (re-)signing:

1) Create your own code signing cert:

In Keychain Access, Keychain Access > Certificate Assistant > Create a certificate. This launches the Certificate Assistant:

Name: Enter some arbitrary string here that you can remember. Avoid spaces otherwise you'll need to escape the cert's name when using codesign from the command line.

Identity type: Self Signed Root

Certificate Type: Code Signing

Check the box "Let me override defaults", this is quite important

Serial number: 1 (OK as long as the cert name/serial no. combination is unique)

Validity Period: 3650 (gives you 10 years)

Email, Name, etc. fill out as you wish.

Key pair info: set to RSA, 2048 bits. Does not really matter IMHO.

From "Key usage extension" up to "Subject Alternate Name Extension": accept the defaults.

Location: login keychain.

Once it is created, set to "Always trust" in the Login keychain.

2) Re-signing an app: codesign -f -s <certname> /path/to/app --deep

3) Verify that it worked: codesign -dvvvv /path/to/app

Enjoy!

share|improve this answer
1  
Thank you! This is the only solution that got rid of the firewall nag dialogs for me. I'm running OSX 10.10 Yosemite. –  Jason Jun 17 at 22:56
1  
very nice! easy for developers who already have a cert, too! –  cwd Jul 29 at 17:57

This relates to whether the app is signed or not. If it's not signed, the preference won't be remembered.

To see if an app is signed do this in Terminal:

cd path/to/your/app
codesign -vvv Eclipse.app/

For Eclipse - mine says it's not signed at all. I can't comment further on how to sign the app since I've not bothered to do that but this answer on superuser covers it:

http://superuser.com/questions/100013/why-does-the-mac-os-x-firewall-dialog-recurringly-pop-up-and-disappear-by-itself#300841

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.