Repeated "Allow incoming connections" dialogues

[blueeye]

Hi all,

This is a problem that people have complained about before but I thought I'd start a new thread because this is about a particular cause.
Essentially, the reason OSX Firewall repeatedly asks whether or not to allow/deny incoming connections with particular apps is that their signatures are invalid. Leopard/Snow Leopard is quite lenient with unsigned software but rather cracks down on invalid signatures.
Now I have this problem with a lot of my apps and so I used

codesign -v /Applications/Coda.app

For example and got back

a sealed resource is missing or invalid

Now I think I've worked out why this is: XSlimmer. I use XSlimmer on almost all my applications because it's useful to slim down the apps but it means that the signature is no longer valid (I checked this hypothesis by testing a freshly downloaded Coda, running XSlimmer and trying again).

It is really annoying to have to always click "allow" every time I use an application so I was wondering if anyone knows a way around this problem without a) disabling the Firewall b) not using XSlimmer.

 

[djcyph]

have u ever installed Little Snitch?

 

[LPZ]

Hi all,

Now I think I've worked out why this is: XSlimmer. I use XSlimmer on almost all my applications because it's useful to slim down the apps but it means that the signature is no longer valid (I checked this hypothesis by testing a freshly downloaded Coda, running XSlimmer and trying again).

Thanks for the post. Perhaps someone else can provide a solution that meets your constraints. My suggestion is to stop using XSlimmer. How large is your hard drive? Is it very full?

 

[GGJstudios]

I've used Monolingual to remove unwanted languages and PPC architectures, and I've never had any problem with signatures being invalid or any firewall issues.

 

[blueeye]

have u ever installed Little Snitch?

No I haven't

My suggestion is to stop using XSlimmer. How large is your hard drive? Is it very full?

The reason for using XSlimmer was application performance. I wanted to get rid of extraneous languages and architectures.

I've used Monolingual to remove unwanted languages and PPC architectures, and I've never had any problem with signatures being invalid or any firewall issues.

It depends on what programmes you've used it on. This problem is a codesign problem and therefore occurs with signed binaries only.
It also depends on whether or not your firewall is switched on.

---

This is of course not a problem limited to XSlimmer but relates to any situation where you have patched a file, modified resources (e.g. to alter iTunes' themes) etc..

 

[LPZ]

The reason for using XSlimmer was application performance. I wanted to get rid of extraneous languages and architectures.

I doubt XSlimmer improves "application performance" in any significant way. It simply appears to reduce "fat binaries" by keeping only the binary for your system's architecture. So it reduces the size of a binary, which will save some space on your HD, but that's about it. With or without XSlimmer, the OS will execute the proper binary for your architecture. Unless your HD space is very limited, you likely gain next to nothing from XSlimmer.

[EDIT] That said, I agree that this OS X behavior is both annoying and odd. Of course you should be asked whether or not to allow the application to receive incoming connections, since the app was signed and has obviously been modified. But you should not be asked again once you've given your answer---unless the package is modified once more. OS X should somehow "re-sign" the modified package, and unless it is changed again, OS X should abide by your original answer. This seems like a flaw in OS X, though perhaps I'm missing something.

 

[GGJstudios]

It depends on what programmes you've used it on. This problem is a codesign problem and therefore occurs with signed binaries only..

Can you give some common app names as examples?

It also depends on whether or not your firewall is switched on.

My firewall is always on.

This is of course not a problem limited to XSlimmer but relates to any situation where you have patched a file, modified resources (e.g. to alter iTunes' themes) etc..

I have altered resources in many apps, and still have had no problem with Monolingual.

 

[LPZ]

As an experiment, I downloaded Coda and unzipped the archive. Then, before launching Coda or modifying the package, I used Terminal:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: code object is not signed

Indeed, the package comes unsigned.

I then removed DebugBeep.nib from Coda.app/Contents/Resources and checked Terminal again:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: code object is not signed

I then opened Coda and chose to allow it to accept incoming connections when I was asked. I then checked Terminal again:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: valid on disk
Coda.app/: satisfies its Designated Requirement

I then quit Coda and reopened again, and was not asked again about incoming connections.

So, my guess is that OS X "signs" the unsigned package when the app is first opened. So if you apply XSlimmer to the package before you ever open the app, maybe you can avoid the problem you've been having.

 

[blueeye]

As an experiment, I downloaded Coda and unzipped the archive. Then, before launching Coda or modifying the package, I used Terminal:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: code object is not signed

Indeed, the package comes unsigned.

I then removed DebugBeep.nib from Coda.app/Contents/Resources and checked Terminal again:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: code object is not signed

I then opened Coda and chose to allow it to accept incoming connections when I was asked. I then checked Terminal again:

LZsMacPro-OSX6: ~/Downloads] codesign -vvv Coda.app/
Coda.app/: valid on disk
Coda.app/: satisfies its Designated Requirement

I then quit Coda and reopened again, and was not asked again about incoming connections.

So, my guess is that OS X "signs" the unsigned package when the app is first opened. So if you apply XSlimmer to the package before you ever open the app, maybe you can avoid the problem you've been having.

Ahh. That is quite interesting (and quite strange).
I haven't bothered using XSlimmer on this install so I may just avoid it altogether...