People using Parental Controls to restrict access to Firefox will presumably also see the problem. In fact, it's not specifically related to authentication at all-the extension is simply pointing out a problem with the app signing that FF is otherwise able to ignore because it doesn't use the Keychain or accept incoming connections by default. The problem is unrelated to the type of authentication mechanism used by the web site. Let me see if I can help clarify the problem at all based on my understanding at this point: I'm the developer of the Keychain Services Integration extension. The possible explanation is what I wrote on the previous comment. On 10.6 - I allowed ('always allow') multiple times, it never 'remembers', I get about 4 prompts for each password. On 10.7 - I allowed ('always allow') once for each password and I never saw the prompt again even after upgrading from b6 to b7, this is the expected behaviour. I went to various sites that required login information that I stored on my keychain. I used the 'Keychain Services Integration' Extension (1.1.3), available at mozilla add-ons page, it's open source and the extension code is available here: Ok, I'm well beyond the testcase scenario now, as we were able to track done the probable cause, and when we found the probable cause (Designated Requirements) we found that being signed by Mozilla is not consider a requirement under Snow Leopard, hence the possible security risk. I ticked the security check box below because I'm unsure of the potential security risk. More information on this issue and how it was found here: # designated => identifier "" and anchor apple Library => identifier "libobjc.A.dylib" and anchor apple or identifier "libstdc++.6.0.9.dylib" and anchor apple or identifier "libSystem.B.dylib" and anchor apple or identifier "libSystem.B.dylib" and anchor apple # designated => identifier "" and anchor apple generic and certificate 1 /* exists */ and certificate leaf /* exists */ and certificate leaf = "43AQ936H96" Library => identifier "libobjc.A.dylib" and anchor apple or identifier "libstdc++.6.0.9.dylib" and anchor apple or identifier "libSystem.B.dylib" and anchor apple $ codesign -d -r- /Applications/Firefox.app/ $ codesign -dvvvv /Applications/Firefox.app/Įxecutable=/Applications/Firefox.app/Contents/MacOS/firefoxįormat=bundle with Mach-O universal (i386 x86_64)ĬodeDirectory v=20100 size=228 flags=0x0(none) hashes=5+3 location=embeddedĬDHash=9a8fac37e22dc161beed715a61bd856896046d58Īuthority=Developer ID Application: Mozilla CorporationĪuthority=Developer ID Certification Authority Other OS X apps signed with Apple Dev certificates don't have this issue, for instance Adium 1.5.1, so it's possible to sign an app in a way that gets recognized by SL.īut digging in the problem might raise a security issue, because on Snow Leopard it is not considering Mozilla's certificate as required, probably meaning that anyone can use their cert to sign a Firefox build? So on SL OS X isn't sure it's the same app so treats it as a different app because it fails DR check and DR check is required to track Keychain Access. Applications/Firefox.app: satisfies its Designated Requirement Applications/Firefox.app: does not satisfy its designated Requirement $ codesign -vvvv /Applications/Firefox.app The problem is probably with the way the builds are signed, specifically their 'Designated Requirements' (DR), on Snow Leopard it fails to satisfy it's DRs, on Lion it satisfies: Now, why this isn't happening is a more complex issue and possibly a security risk. In Snow Leopard it should have the same behaviour as with Lion. On Snow Leopard it's the opposite, it keeps prompting the user for keychain access. Using 'Keychain Services Integration' extension on Firefox works flawlessly on OSX Lion, once Keychain access is allowed ('always allow') to a password the user never gets prompted again, even after upgrading Firefox. I tried using 'Keychain Services Integration' extension with Firefox 14 (signed build).
0 Comments
Leave a Reply. |