search

jfitzell / mozilla-keychain

Store your Firefox website usernames and passwords in Apple's Keychain Services, just like Safari and other browsers do on OS X.
55 stars 9 forks source link

Problem with Firefox 13 / Keychain 4.1.1 / Mac OS 10.6.8 - Multiple Authorizations Needed #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. In Firefox 13 . . . anything that requires a saved password from Keychain.
2.
3.

What is the expected output? What do you see instead?
I would expect Keychain to request my authorization to access.  Instead I get 
the same authorization window that I would expect saying "always allow, deny, 
allow" but have to click allow or always allow at least 48 times before the 
password will populate.  Then, even if I've clicked "always allow" the very 
next time I go to that page and need to password to populate again I have to 
repeat the process and click allow or always allow a least 48 times more to get 
the password to populate.

What version of the product are you using? On what operating system?
Mac OS: 10.6.8
Firefox: 13
Keychain: 4.1.1

Please provide any additional information below.

Original issue reported on code.google.com by evensti...@gmail.com on 7 Jun 2012 at 2:02

GoogleCodeExporter commented 9 years ago 
same or related issue with the same versions:
each time keychain is told to "always allow", it creates a new entry for 
firefox in "access control" for the item in question; see attachment.
downgrading firefox to 12 fixes it.

Original comment by ark...@googlemail.com on 9 Jun 2012 at 9:55

Attachments:

GoogleCodeExporter commented 9 years ago 
Having the same issue as well. The "always allow" option does not seem to be 
taken into account, and FF keeps on asking for my authorization. Mac OS 10.6, 
FF 14 (beta channel).

Original comment by pabuis...@gmail.com on 9 Jun 2012 at 12:01

GoogleCodeExporter commented 9 years ago 
I'll need to dig into this to see what's up, but I'm afraid it will likely be a 
couple of weeks before I have much time... in the meantime, I guess downgrading 
to FF 12 is the solution.

Original comment by jfitz...@gmail.com on 10 Jun 2012 at 11:39

GoogleCodeExporter commented 9 years ago 
Issue 49 has been merged into this issue.

Original comment by jfitz...@gmail.com on 10 Jun 2012 at 11:40

GoogleCodeExporter commented 9 years ago 
This started occurring at/about the same time signed builds where implemented, 
a situation (signed builds) that would greatly improve Keychain Service, but 
seems to be making the opposite.

Might be interesting to note the following:

$ codesign -vvvv /Applications/Firefox.app
/Applications/Firefox.app: valid on disk
/Applications/Firefox.app: does not satisfy its designated Requirement

Original comment by spini...@gmail.com on 11 Jun 2012 at 5:35

GoogleCodeExporter commented 9 years ago 
PS: I should add I'm on 10.6.8 too.

Original comment by spini...@gmail.com on 11 Jun 2012 at 8:38

GoogleCodeExporter commented 9 years ago 
Thanks... it will definitely be related to the signed builds, and I kind of 
guessed it would be something like what you've found — OS X is not happy when 
signed builds are no longer correct. As you say, it *should* improve the 
situation but seems to be having the opposite effect. The first question is, is 
it broken with a brand new install as well or only when upgrading from an 
unsigned build?

The second question will be what is the nature of the Requirement failure...

Original comment by jfitz...@gmail.com on 11 Jun 2012 at 10:20

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Both situations, I've upgraded as well as deleted the app and download a brand 
new one, I've even reset the keychain and imported the passwords from the old 
one, keychain first aid, etc, still the same.

Also, by both situations I also mean that a freshly signed build will also give 
the "does not satisfy its designated Requirement".

I thinking an interesting experiment would be to delete _CodeSignature and see 
if we still get multiple prompts (besides the new ones with a new version).

Original comment by spini...@gmail.com on 11 Jun 2012 at 11:02

GoogleCodeExporter commented 9 years ago 
By new install, I meant an install of OS X that hasn't had Firefox before. It 
probably won't make any difference but you never know what's been written into 
the signing database and I know if you run an unsigned application it gets 
self-signed.

Original comment by jfitz...@gmail.com on 12 Jun 2012 at 11:45

GoogleCodeExporter commented 9 years ago 
Ok, I decided to make some testing on a Lion VM that never seen Firefox before.

The OSX version on it is 10.7.3 (sorry I hadn't time to upgrade to .4, don't 
know if that makes a difference).

Firefox version is 14.0b6 (beta)

The fresh installation gives these results:
$ codesign -vvvv /Applications/Firefox.app
/Applications/Firefox.app: valid on disk
/Applications/Firefox.app: satisfies its Designated Requirement

and Keychain Service Integration extension works flawlessly, once it saves a 
password and has teh 'always allow' it never prompts again, I haven't tried 
upgrading, I'll wait for the next beta upgrade (probably in a week or so) to 
see what happens.

So your theory seems to be correct, but because my problems with the keychain 
integration are in Snow Leopard I wonder if the problem is with signed 
applications in Snow Leopard or the fact that I already had firefox before. On 
the first possibility I should add that Adium 1.5.1, which is now also signed 
with an Apple Dev cert, and uses keychain stored passwords, has none of these 
problems, and works as expected.

Original comment by spini...@gmail.com on 12 Jun 2012 at 3:40

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
> More testing > Upgrading
Ok... new Firefox Beta build today, 14.0b7, tested on the Lion VM, everything 
ok, upgrade didn't break the signing, and doesn't ask to allow access to a 
stored password. Perfect.

On my Snow Leopard non-VM, upgraded to b7, still he same problems (didn't 
expected this to change anyway).

> More information
I dug around for more information, that might be helpful...

I was reading this: 
http://developer.apple.com/library/mac/#technotes/tn2206/_index.html

(not sure if it's up to date)

The part that refers how Keychain Access by an App is tracked it states the 
following:

"Free access to the keychain item by the creating application and tracked with 
its DR (No automatic tracking for custom ACLs)."
(DR meaning Designated Requirement)

So, ACLs and DR come into play here, the fact that it does not satisfy DR on my 
Mac seems to be directly related.

Original comment by spini...@gmail.com on 14 Jun 2012 at 10:03

GoogleCodeExporter commented 9 years ago 
Thanks for digging in. Yes, I'm quite sure the fact that it's failing to 
satisfy is causing the problem—once the signing is invalidated, OS X locks 
permissions down on the application quite tightly.

Wonder if this is related?
http://www.red-sweater.com/blog/2390/developer-id-gotcha

Is it just a 10.6/10.7 issue with the FF build?

Original comment by jfitz...@gmail.com on 14 Jun 2012 at 10:09

GoogleCodeExporter commented 9 years ago 
That might be it, I wish I had a 10.6.8 fresh installation to test this.

By the way, I had already brought up this problem on bugzilla on "Bug 723176 - 
support mac dmg signing in the build system" : 
https://bugzilla.mozilla.org/show_bug.cgi?id=723176

Original comment by spini...@gmail.com on 14 Jun 2012 at 10:52

GoogleCodeExporter commented 9 years ago 
Just for completeness, I downloaded FF 13 and checked the signature of the .app 
while still in the .dmg:

$ codesign -dvvvv /Volumes/Firefox/Firefox.app
Executable=/Volumes/Firefox/Firefox.app/Contents/MacOS/firefox
Identifier=org.mozilla.firefox
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=228 flags=0x0(none) hashes=5+3 location=embedded
CDHash=160fec052c26b4c2b41196920c564c9e64a44719
Signature size=4232
Authority=Developer ID Application: Mozilla Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=Jun 1, 2012 4:14:17PM
Info.plist entries=18
Sealed Resources rules=12 files=94
Internal requirements count=1 size=152

$ codesign -d -r- /Volumes/Firefox/Firefox.app
Executable=/Volumes/Firefox/Firefox.app/Contents/MacOS/firefox
library => 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 "org.mozilla.firefox" and anchor apple

Original comment by jfitz...@gmail.com on 14 Jun 2012 at 11:26

GoogleCodeExporter commented 9 years ago 
Here's the results from Adium (which works correctly with the keychain on 10.6):

$ codesign -dvvvv /Applications/Adium.app/
Executable=/Applications/Adium.app/Contents/MacOS/Adium
Identifier=com.adiumX.adiumX
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=10746 flags=0x0(none) hashes=531+3 location=embedded
CDHash=43d67cc521ea4eb46ccb45cb3d4672b654865904
Signature size=4256
Authority=Developer ID Application: Instant Messaging Freedom, Inc.
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=2012/06/07 00:13:12
Info.plist entries=41
Sealed Resources rules=4 files=1940
Internal requirements count=2 size=1084

$ codesign -d -r- /Applications/Adium.app/
Executable=/Applications/Adium.app/Contents/MacOS/Adium
designated => anchor apple generic and identifier "com.adiumX.adiumX" and 
(certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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] = VQ6ZEL8UD3)
library => identifier "com.apple.QuickTime" and anchor apple or identifier 
"com.apple.Cocoa" and anchor apple or identifier "libexpat.1" and anchor apple 
or identifier "libcrypto.0" and anchor apple or identifier "com.apple.WebKit" 
and anchor apple or identifier "com.apple.AddressBook.framework" and anchor 
apple or identifier "com.apple.Carbon" and anchor apple or identifier 
"com.apple.ExceptionHandling" and anchor apple or identifier 
"com.apple.SystemConfiguration" and anchor apple or identifier 
"com.apple.quartzframework" and anchor apple or identifier "com.apple.security" 
and anchor apple or identifier "com.apple.audio.CoreAudio" and anchor apple or 
identifier "com.apple.QTKit" and anchor apple or identifier "libSystem.B" and 
anchor apple or identifier "libobjc.A" and anchor apple or identifier 
"com.apple.CoreServices" and anchor apple or identifier 
"com.apple.CoreFoundation" and anchor apple or identifier 
"com.apple.ApplicationServices" and anchor apple or identifier 
"com.apple.Foundation" and anchor apple or identifier "com.apple.QuartzCore" 
and anchor apple or identifier "com.apple.AppKit" and anchor apple

Original comment by spini...@gmail.com on 15 Jun 2012 at 1:15

GoogleCodeExporter commented 9 years ago 
The curious thing is that the FF one actually seems less specific. It doesn't 
even seem to require that it be signed by mozilla, which seems like a bit of a 
problem from a malware point of view...

I'm guessing the problem is actually the "anchor apple" instead of "anchor 
apple generic"? (see below) I wonder if that's being specified or automatically 
generated? What's the output of "codesign -d -r-" for FF on your 10.7 machine?

"For Apple’s own code, signed by Apple, you can use the short form

anchor apple

For code signed by Apple, including code signed using a signing certificate 
issued by Apple to other developers, use the form

anchor apple generic"

https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeS
igningGuide/RequirementLang/RequirementLang.html

Original comment by jfitz...@gmail.com on 15 Jun 2012 at 8:33

GoogleCodeExporter commented 9 years ago 
> Here it is, FF 14.0b7 on OSX 10.7.3:

$ codesign -dvvvv /Applications/Firefox.app/
Executable=/Applications/Firefox.app/Contents/MacOS/firefox
Identifier=org.mozilla.firefox
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=228 flags=0x0(none) hashes=5+3 location=embedded
Hash type=sha1 size=20
CDHash=9a8fac37e22dc161beed715a61bd856896046d58
Signature size=4232
Authority=Developer ID Application: Mozilla Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=13/06/2012 02:08:53
Info.plist entries=17
Sealed Resources rules=12 files=94
Internal requirements count=1 size=148

$ codesign -d -r- /Applications/Firefox.app/
Executable=/Applications/Firefox.app/Contents/MacOS/firefox
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
# designated => identifier "org.mozilla.firefox" 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] = "43AQ936H96"

>Just for comparison, FF 14.0b7 on OSX 10.6.8:

$ codesign -dvvvv /Applications/Firefox.app/
Executable=/Applications/Firefox.app/Contents/MacOS/firefox
Identifier=org.mozilla.firefox
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=228 flags=0x0(none) hashes=5+3 location=embedded
CDHash=1a480ca9e27748ff50eaf1db36b3a5f4e96b8aa2
Signature size=4232
Authority=Developer ID Application: Mozilla Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=2012/06/13 02:08:53
Info.plist entries=17
Sealed Resources rules=12 files=94
Internal requirements count=1 size=188

$ codesign -d -r- /Applications/Firefox.app/
Executable=/Applications/Firefox.app/Contents/MacOS/firefox
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 "org.mozilla.firefox" and anchor apple

On Lion it does indeed appear as 'anchor apple generic', but on SL it is 
'anchor apple'. So I guess this is it.

Original comment by spini...@gmail.com on 15 Jun 2012 at 10:59

GoogleCodeExporter commented 9 years ago 
Yes, it *seems* like the default is being applied and on 10.6 that ends up 
checking for the application having been written by apple, which presumably is 
failing.

I'm not sure how to test further without support from Mozilla - it really seems 
like they need to include a manually specified DR... perhaps we can motivate 
the fix by pointing out that on 10.5 it doesn't even insist on signing by 
Mozilla.

Original comment by jfitz...@gmail.com on 15 Jun 2012 at 11:18

GoogleCodeExporter commented 9 years ago 
Indeed, that would be the best motivation for them, at least that would 
escalate the importance of the issue, I think we need to open a new bug on 
bugzilla for this.

Original comment by spini...@gmail.com on 15 Jun 2012 at 11:28

GoogleCodeExporter commented 9 years ago 
Opened bug 765271 on bugzilla, not publicly visible as I marked as a potential 
security risk.

Original comment by spini...@gmail.com on 15 Jun 2012 at 4:45

GoogleCodeExporter commented 9 years ago 
I've just updated to firefox 13.0.1 and i still got this problem. Is there any 
way i can somehow soften it? It's driving me nuts and seriously considering 
erasing Firefox from my mac for good. 

After this bug is fixed, what will happen to the endless entrys by Firefox in 
Access control in Keychain on each acount/password pair? Should do some sort of 
cleanup? and can we avoid doing it manually?

Original comment by lordjeremias on 19 Jun 2012 at 12:42

GoogleCodeExporter commented 9 years ago 
I'm afraid the problem will continue until Mozilla fixes its binary signing to 
work with OS X 10.6 (I assume you are running 10.6—you don't say). For now, I 
would suggest:

- Downgrade to FF 12: 
https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/12.0/
- Add a comment telling Mozilla this problem is important to you: 
https://bugzilla.mozilla.org/show_bug.cgi?id=765271

The duplicate entries in Keychain are only partially related to this problem. 
You will already have been getting one entry for every version of Firefox in 
the past, due to the builds not being signed. I guess you're seeing one per 
prompt now because of the incorrect signing. I don't know of an easy way to 
clean them up, though I might look into it at some point once Mozilla fixes the 
problem.

Original comment by jfitz...@gmail.com on 19 Jun 2012 at 1:09

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Lordjere, I feel your pain. But I can give a couple of suggestions in addition 
to jfitz's.

- Use 'allow' instead of 'always allow' so you don't add unnecessary entries to 
the keychain, until the problem is solved.
- Use the 'keep me connected' functionality in sites so they don't ask for 
passwords. 
- I cleaned up my Keychain manually, removed all entries of Firefox from each 
password item, for each password you can use shift, ctrl or a dragging a mouse 
window to selected all entries of Firefox.

Original comment by spini...@gmail.com on 19 Jun 2012 at 1:55

GoogleCodeExporter commented 9 years ago 
Or upgrade to OS X 10.7, of course.

Original comment by jfitz...@gmail.com on 19 Jun 2012 at 2:05

GoogleCodeExporter commented 9 years ago 
Hi, yes, it's 10.6.8, completly forgot to mention that. 

I've already voted on the bugzilla report and joined the cc list, let's hope 
they fix this as soon as possible. 

Downgraded to Firefox 12 as advised. I'll let you know if i have any more 
problems.

(regarding OS X 10.7, i'll pass thank you. not an improvement at all)

Original comment by lordjeremias on 19 Jun 2012 at 2:14

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I have another (possible, not fully tested) workaround for those who are 
technically inclined:

1) Create a self-signed code signing certificate:
  a) Launch Keychain Access
  b) On the Keychain Access menu, choose Certificate Assistant --> Create a Certificate...
    - Name: Test Signing Certificate
    - Identity Type: Self Signed Root
    - Certificate Type: Code Signing
    - Let me override default: unchecked
  c) Accept and close any the dialogs
2) Resign the Firefox binary:
  a) Open Terminal.app
  b) Execute the following (when prompted, you'll need to allow access to the certificate you created):
    codesign --sign "Test Signing Certificate" --force --requirements "=designated => identifier \"org.mozilla.firefox\" and info [CFBundleShortVersionString] < \"14.0\"" --resource-rules=/Applications/Firefox.app/Contents/CodeResources /Applications/Firefox.app
  c) Make sure it worked by running
    codesign -vvvv /Applications/Firefox.app
  and checking for the line "Firefox.app: satisfies its Designated Requirement"

You'll need to re-sign each new version as you upgrade and note that the above 
is set to only work for version 13... you'll really want to go back to 
Mozilla's version once they get it fixed (which will hopefully be in v14) at 
which point you'll hopefully get prompted once more and then never again!

Original comment by jfitz...@gmail.com on 19 Jun 2012 at 7:28

GoogleCodeExporter commented 9 years ago 
Just to make it more clear to unexperienced codesign people like me:
point 2-b "you'll need to allow access to the certificate you created)" means 
you have to open the keychain than go to my certificates, click the triangle in 
the "Test Signing Certificate", double click on the "Test Signing Certificate" 
(the one with a key icon), go on the Access Control tab and add Firefox in the 
list.

In my case codesign command complained that the resource file couldn't be 
found, but worked with this command:
codesign --sign "Test Signing Certificate" --force --requirements "=designated 
=> identifier \"org.mozilla.firefox\" and info [CFBundleShortVersionString] < 
\"14.0\"" /Applications/Firefox.app/

Original comment by tommaso....@gmail.com on 26 Jun 2012 at 7:55

GoogleCodeExporter commented 9 years ago 
Hm... 2b *should* just mean that when you run the command a dialog pops up 
asking you to allow access (and it would be to the codesign application, not 
Firefox). But perhaps something is different on my machine (I'm no codesign 
expert myself, though rapidly becoming one :) )

Glad you got it working in any case. We believe we've given the correct fix to 
Mozilla and now just hope they can test and integrate it before FF14 is 
released...

Original comment by jfitz...@gmail.com on 26 Jun 2012 at 5:03

GoogleCodeExporter commented 9 years ago 
Ok, this has now been fixed by Mozilla. All future releases will work fine... 
there should be a new beta of FF14 coming out at the end of the week which 
people can upgrade to if desired, or if you've done one of the above 
workarounds, just wait for FF14 to roll into stable.

Original comment by jfitz...@gmail.com on 3 Jul 2012 at 11:21