[jitsi-dev] Issue Report: Firewall prompt whenever Jitsi is started, doesn't remember setting


#1

Specs: Fully updated Mac OS X 10.6.8 with Jitsi: 2.0.4506.10553

Hi there,

There is a problem with the codesigning of Jitsi on OS X 10.6 which results
in the Firewall always asking for for permission to Allow it when Jitsi is
started. I'm very familiar with this problem as I helped to solve it for
Mozilla Firefox. This problem does not occur in Lion and Mountain Lion due
to differences in code signing.

Here's the bug on Firefox, in its case it was related to keychain access,
but the problem is the same for firewall access as it relies on code
signature: https://bugzilla.mozilla.org/show_bug.cgi?id=765271

Basically, the fact the code signing is valid on Lion and Mountain it
doesn't mean it's valid on Snow Leopard.

"the short version is that you should always supply your own designated
requirement, rather than letting the codesigning system choose the one
that's appropriate only for the OS on which the app is signed."

On Snow Leopard:

$ codesign -vvvv /Applications/Jitsi.app/

/Applications/Jitsi.app/: valid on disk

/Applications/Jitsi.app/: does not satisfy its designated Requirement

$ codesign -dvvvv /Applications/Jitsi.app/

Executable=/Applications/Jitsi.app/Contents/MacOS/Jitsi

Identifier=org.jitsi

Format=bundle with Mach-O universal (i386 ppc)

CodeDirectory v=20100 size=198 flags=0x0(none) hashes=4+3 location=embedded

CDHash=a501e620ddb5bd490c5713c9a1978ea279a640f5

Signature size=4209

Authority=Developer ID Application: BlueJimp

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Signed Time=2013/03/03 03:59:42

Info.plist entries=20

Sealed Resources rules=4 files=152

Internal requirements count=1 size=188

The fact that it does not satisfy its designated Requirement is what makes
the OS X firewall not trust that the app is the same and hasn't been
tampered with.

Best regards,

Pedro


#2

Hey Pedro,

thank you very much for the report and the explanations. I was looking
at the discussions about this and managed to modify our build
procedure to supply the designated requirement as you suggested, can
you please test such a binary which was build to test the new rules,
and report do you think it is ok now? Cause I don't have currently
access to Mac OS X 10.6.8.
Here is the dmg:
https://download.jitsi.org/jitsi/nightly/test/jitsi-2.1.4520.10590.dmg

Thanks once again
damencho

···

On Fri, Mar 8, 2013 at 10:28 PM, P. B. <spinifer@gmail.com> wrote:

Specs: Fully updated Mac OS X 10.6.8 with Jitsi: 2.0.4506.10553

Hi there,

There is a problem with the codesigning of Jitsi on OS X 10.6 which results
in the Firewall always asking for for permission to Allow it when Jitsi is
started. I'm very familiar with this problem as I helped to solve it for
Mozilla Firefox. This problem does not occur in Lion and Mountain Lion due
to differences in code signing.

Here's the bug on Firefox, in its case it was related to keychain access,
but the problem is the same for firewall access as it relies on code
signature: https://bugzilla.mozilla.org/show_bug.cgi?id=765271

Basically, the fact the code signing is valid on Lion and Mountain it
doesn't mean it's valid on Snow Leopard.

"the short version is that you should always supply your own designated
requirement, rather than letting the codesigning system choose the one
that's appropriate only for the OS on which the app is signed."

On Snow Leopard:

$ codesign -vvvv /Applications/Jitsi.app/

/Applications/Jitsi.app/: valid on disk

/Applications/Jitsi.app/: does not satisfy its designated Requirement

$ codesign -dvvvv /Applications/Jitsi.app/

Executable=/Applications/Jitsi.app/Contents/MacOS/Jitsi

Identifier=org.jitsi

Format=bundle with Mach-O universal (i386 ppc)

CodeDirectory v=20100 size=198 flags=0x0(none) hashes=4+3 location=embedded

CDHash=a501e620ddb5bd490c5713c9a1978ea279a640f5

Signature size=4209

Authority=Developer ID Application: BlueJimp

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Signed Time=2013/03/03 03:59:42

Info.plist entries=20

Sealed Resources rules=4 files=152

Internal requirements count=1 size=188

The fact that it does not satisfy its designated Requirement is what makes
the OS X firewall not trust that the app is the same and hasn't been
tampered with.

Best regards,

Pedro


#3

Hi,

thank you for the quick test,
committed the fix and acked on the team page.

Thanks
damencho

···

On Tue, Mar 12, 2013 at 4:50 PM, Pedro M.B. <spinifer@gmail.com> wrote:

Hey Damian, thank you for looking into this,

Replaced the current stable in my system with the download you provided. Just one first firewall prompt to allow connections and all the subsequent launches have been prompt free, also, running the codesign checks now says it satisfies its designated requirements:

$ codesign -vvvv /Applications/Jitsi.app
/Applications/Jitsi.app: valid on disk
/Applications/Jitsi.app: satisfies its Designated Requirement

$ codesign -dvvvv /Applications/Jitsi.app
Executable=/Applications/Jitsi.app/Contents/MacOS/Jitsi
Identifier=org.jitsi
Format=bundle with Mach-O universal (i386 ppc)
CodeDirectory v=20100 size=198 flags=0x0(none) hashes=4+3 location=embedded
CDHash=4cf4cb009448059b1f1e253e2a95f0719f774a40
Signature size=4209
Authority=Developer ID Application: BlueJimp
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=2013/03/12 13:51:02
Info.plist entries=20
Sealed Resources rules=4 files=152
Internal requirements count=2 size=348

$ codesign -d -r- /Applications/Jitsi.app
Executable=/Applications/Jitsi.app/Contents/MacOS/Jitsi
designated => identifier "org.jitsi" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = BE8738ZVRM
library => identifier "com.apple.JavaApplicationLauncher" and anchor apple or identifier "com.apple.Foundation" and anchor apple or identifier "libSystem.B" and anchor apple or identifier "libSystem.B" and anchor apple

It seems to be working fine now! Thanks!

Pedro Bidarra

On 2013/03/12, at 14:12, Damian Minkov wrote:

Hey Pedro,

thank you very much for the report and the explanations. I was looking
at the discussions about this and managed to modify our build
procedure to supply the designated requirement as you suggested, can
you please test such a binary which was build to test the new rules,
and report do you think it is ok now? Cause I don't have currently
access to Mac OS X 10.6.8.
Here is the dmg:
https://download.jitsi.org/jitsi/nightly/test/jitsi-2.1.4520.10590.dmg

Thanks once again
damencho

On Fri, Mar 8, 2013 at 10:28 PM, P. B. <spinifer@gmail.com> wrote:

Specs: Fully updated Mac OS X 10.6.8 with Jitsi: 2.0.4506.10553

Hi there,

There is a problem with the codesigning of Jitsi on OS X 10.6 which results
in the Firewall always asking for for permission to Allow it when Jitsi is
started. I'm very familiar with this problem as I helped to solve it for
Mozilla Firefox. This problem does not occur in Lion and Mountain Lion due
to differences in code signing.

Here's the bug on Firefox, in its case it was related to keychain access,
but the problem is the same for firewall access as it relies on code
signature: https://bugzilla.mozilla.org/show_bug.cgi?id=765271

Basically, the fact the code signing is valid on Lion and Mountain it
doesn't mean it's valid on Snow Leopard.

"the short version is that you should always supply your own designated
requirement, rather than letting the codesigning system choose the one
that's appropriate only for the OS on which the app is signed."

On Snow Leopard:

$ codesign -vvvv /Applications/Jitsi.app/

/Applications/Jitsi.app/: valid on disk

/Applications/Jitsi.app/: does not satisfy its designated Requirement

$ codesign -dvvvv /Applications/Jitsi.app/

Executable=/Applications/Jitsi.app/Contents/MacOS/Jitsi

Identifier=org.jitsi

Format=bundle with Mach-O universal (i386 ppc)

CodeDirectory v=20100 size=198 flags=0x0(none) hashes=4+3 location=embedded

CDHash=a501e620ddb5bd490c5713c9a1978ea279a640f5

Signature size=4209

Authority=Developer ID Application: BlueJimp

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Signed Time=2013/03/03 03:59:42

Info.plist entries=20

Sealed Resources rules=4 files=152

Internal requirements count=1 size=188

The fact that it does not satisfy its designated Requirement is what makes
the OS X firewall not trust that the app is the same and hasn't been
tampered with.

Best regards,

Pedro