Last Comment Bug 765271 - Bugs in Apple's codesigning for apps signed with Apple signing certs, which cause problems accessing the Keychain
: Bugs in Apple's codesigning for apps signed with Apple signing certs, which c...
Status: RESOLVED FIXED
:
Product: Release Engineering
Classification: Other
Component: General Automation (show other bugs)
: other
: x86 Mac OS X
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Chris AtLee [:catlee]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-15 09:34 PDT by spinifer
Modified: 2013-08-12 21:54 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
+
verified
+
verified


Attachments
Example of CodeResources that work on <10.7 from Adium 1.5.1 (283.71 KB, text/plain)
2012-06-19 09:35 PDT, spinifer
no flags Details
Proposed DR (420 bytes, text/plain)
2012-06-19 12:03 PDT, Julian Fitzell
no flags Details
update signing server to support designated requirements (5.51 KB, patch)
2012-06-29 06:23 PDT, Ben Hearsum (:bhearsum)
catlee: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
akeybl: approval‑mozilla‑release+
akeybl: approval‑mozilla‑esr10-
bhearsum: checked‑in+
Details | Diff | Review
puppet manifest updates (1.89 KB, patch)
2012-06-29 06:26 PDT, Ben Hearsum (:bhearsum)
catlee: review+
bhearsum: checked‑in+
Details | Diff | Review

Description spinifer 2012-06-15 09:34:32 PDT
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120612164001

Steps to reproduce:

I tried using 'Keychain Services Integration' extension with Firefox 14 (signed build).


Actual results:

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.

On Snow Leopard it's the opposite, it keeps prompting the user for keychain access.


Expected results:

In Snow Leopard it should have the same behaviour as with Lion. Now, why this isn't happening is a more complex issue and possibly a security risk.
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:

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

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

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.

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.

But 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?

> 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

---

More information on this issue and how it was found here: http://code.google.com/p/mozilla-keychain/issues/detail?id=48

It is also referred to here: https://bugzilla.mozilla.org/show_bug.cgi?id=723176

---

I ticked the security check box below because I'm unsure of the potential security risk.
Comment 1 Steven Michaud [:smichaud] (Retired) 2012-06-15 09:48:30 PDT
You haven't given us a testcase (one that we can test with ourselves).  You need to.

Please also provide detailed steps to reproduce.

A testcase would be something like "I used 'Keychain Services Integration' to do [whatever], and it failed in such-and-such a way", with detailed steps to follow.

Where can you get "Keychain Services Integration"?  Is it open-source?
Comment 2 Steven Michaud [:smichaud] (Retired) 2012-06-15 09:49:23 PDT
I think it's very unlikely this bug has security consequences.  But I can't know for sure until you provide a testcase.
Comment 3 spinifer 2012-06-15 10:00:38 PDT
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. 

Anyway, here we go...

Testcase:

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:

http://code.google.com/p/mozilla-keychain/

With Firefox 14.0b6/b7 on OS X 10.6.8 and 10.7.3.

I went to various sites that required login information that I stored on my keychain.

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.

On 10.6 - I allowed ('always allow') multiple times, it never 'remembers', I get about 4 prompts for each password.

The possible explanation is what I wrote on the previous comment.
Comment 4 Steven Michaud [:smichaud] (Retired) 2012-06-15 10:07:17 PDT
> I went to various sites that required login information that I stored on my
> keychain.

Did any these sites use http basic auth?

I ask because I'm probably going to have to set up my own site to test with, and http basic auth is probably the easiest kind of login to set up.
Comment 5 spinifer 2012-06-15 10:16:39 PDT
Mostly very well known sites like facebook and gmail. But I think my home router uses http basic auth, and the problem is the same as with other sites. As I'm inclined to think it's related to the access rights tracking to saved passwords (with keychain services integration they are stored in OSX login keychain instead of Firefox password storage).
Comment 6 spinifer 2012-06-15 10:28:10 PDT
Ok, I confirmed one of our network copiers/printers uses Basic Auth for its web page, and I confirmed this bug happens in this ituation also. :)
Comment 7 Steven Michaud [:smichaud] (Retired) 2012-06-15 10:32:11 PDT
Thanks!

Like I said, I probably can't get to this right away.

But now I probably have everything I need to work with.
Comment 8 spinifer 2012-06-15 10:34:13 PDT
Thanks for looking into this, any more information you need just ask away.
Comment 9 Smokey Ardisson (offline for a while; not following bugs - do not email) 2012-06-15 11:27:06 PDT
http://mjtsai.com/blog/2012/03/20/developer-id-gotcha/ explains the problem and provides a couple of ways to fix it; 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.
Comment 10 spinifer 2012-06-15 15:02:00 PDT
Also here: http://www.red-sweater.com/blog/2390/developer-id-gotcha
Comment 11 Daniel Veditz [:dveditz] 2012-06-16 09:13:22 PDT
We've only recently started signing Mac builds, and we're doing so primarily due to 10.8 requirements than for security reasons. I'm unhiding the bug so the access restrictions don't hinder getting this fixed.
Comment 12 Ovidiu 2012-06-19 06:27:40 PDT
Same problem here on OSX 10.6.8, FF 13.0 and Keychain Services Integration. Would very much appreciate fixing this, the system keeps asking for access permission every time Firefox needs a password which is extremely annoying. Keychain Services Integration was amazing and brought Firefox finally in line with Safari and Chrome.
Comment 13 Julian Fitzell 2012-06-19 06:48:28 PDT
I'm the developer of the Keychain Services Integration extension. Let me see if I can help clarify the problem at all based on my understanding at this point:

The problem is unrelated to the type of authentication mechanism used by the web site. 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. People using Parental Controls to restrict access to Firefox will presumably also see the problem. I'm not sure if there are other parts of OS X that rely on signing.

The extension simply directs all FF stored passwords to the OS X Keychain. Whenever an app tries to read a password from the keychain, OS X checks the signature of the app. When a user tells OS X to "Always Allow", this is noted and future requests by the same application are allowed automatically. The "same application" is defined as any application that matches the Designated Requirement (DR) of the original application.

By not having manually specified a DR when signing the FF binary, OS X is using a default DR. Unfortunately, the default DR on OS X 10.6 is inappropriate when using an Apple Developer certificate for signing. As a result, FF13 currently fails to meet its own DR on OS X 10.6 and the operating system thinks that every request is from a new application, thus breaking Keychain Services, Application Firewall, and Parental Controls.

The possible security implication is related, though not the same. The default DR for FF 13 on OS X 10.6 does not appear to specify the signing authority (on 10.7 you'll see 'certificate leaf[subject.OU] = "43AQ936H96"', but not on 10.6). In theory, the absence of that clause would allow anybody to create an app with Firefox's identifier, sign it, and have it access services authorized by the user only for the Firefox binary. It shouldn't actually be a security problem at the moment given that a signature by Apple is being required for FF to meet its own DR, but if the default DR were different (and it could be on different OS X versions) then there could be a problem. The fix, as specified in the links shared in Comment 9 and Comment 10, are to always manually specify an appropriate DR when signing. I assume it should be a straightforward adjustment to the build scripts to do so?

Do let me know if I can be of further assistance.
Comment 14 Steven Michaud [:smichaud] (Retired) 2012-06-19 07:25:23 PDT
Thanks, jfitzell!

When I get back to this (which won't be for a while) I'll try explicitly setting the signing authority in the designated requirements, and see what happens.

This sounds very much like an Apple bug -- one that was fixed in OS X 10.7.

Interesting what you say about parental controls.  It exactly matches what's reported in bug 763956.
Comment 15 Julian Fitzell 2012-06-19 07:37:20 PDT
Hi Steven,

Any chance you could expand on the meaning of "for a while" at all? There are 2000 daily users of Keychain Services Integration who are all going to be breathing down my neck as they try to upgrade and find it broken. I understand you'll be busy with many things, but I'd like to at least know what to tell them. At the moment all I can say is "downgrade to FF12 and wait for a fix..."

Also, if you could give a pointer to the specific build script involved on your end, perhaps one of those 2000 users might be coaxed into speeding up the process by creating a patch for testing...
Comment 16 Steven Michaud [:smichaud] (Retired) 2012-06-19 07:53:01 PDT
By "for a while" I mean a few weeks.

I don't know where the scripts are that do the signing.  But I know what they do.  And if I find a way to change how we sign Firefox that successfully works around Apple's bug, I can ask the appropriate people to change our signing scripts.

There's one thing you could do, Julian, to help speed up the process.  Get an app signing cert from Apple (if you don't already have one), and see if *you* can find a way to change how we sign Firefox that fixes this bug.  You'd (of course) be testing with a Firefox build that you'd signed.  But Mozilla has the same kind of signing cert (an app signing cert from Apple).  So whatever worked with your cert should also work with Mozilla's.

We already explicitly set our requirements, using the "rules" section of Firefox's embedded CodeResources plist file.  Make a copy of the file and edit out the "files" section.  This is the file you'll want to play with in your tests.

As I understand it, here's the command we use to sign Firefox:

codesign -s [Mozilla] -r rules.plist Firefox.app

If you can come up with a workaround, all I'd need do myself is verify it and pass it along to the appropriate people.  That'd save me a lot of time.
Comment 17 Ben Hearsum (:bhearsum) 2012-06-19 08:09:04 PDT
As one of the people who worked directly on our OS X signing infrastructure, I don't think it's useful for people to hack directly on it. As Steven says, if you can figure out what the CodeResources and codesign invocation needs to look like, we should be able to do the rest pretty quickly. Do be aware that it's unlikely we'd spin a special release just for this, though. Even if we have a fix ready this fix it's unlikely to ship before Firefox 14.0.

Thank you for your knowledge and time spent here.
Comment 18 lordjeremias 2012-06-19 08:31:29 PDT
hi folks,

i won't comment on the rest as i don't have enough technical kung-fu but just a quick word about this: 
"Do be aware that it's unlikely we'd spin a special release just for this, though. Even if we have a fix ready this fix it's unlikely to ship before Firefox 14.0."

You do realize that this pretty much makes Firefox unusable for Mac users that rely on Keychain right? I mean, yesterday i was trying out Camino or  seeking out how i could create a second independent profile on Chrome (i use firefox as a "work only" browser). 

I don't get why Firefox doesn't integrate better with Mac supplied infrastructures to begin with (Keychain, PDF Preview, Mac OS wide Spell-checking) but seeing that it doesn't and this extension is the only way we can use Keychain, if "all" it takes is fixing the signature options and signing it again, why must we wait till Firefox 14? a simple 14.0.2 (mac only) update would do the trick. 

With this i don't mean that it's easy to find out what needs to be done to correct it, i'm just saying that a delay on this, even after you found out the solution, for another 6 weeks or so is a royal PITA and pretty much a  no-go for those that depend on this extension to use Firefox at ALL!

Despite this, many thanks for your work on Firefox though!
Comment 19 Steven Michaud [:smichaud] (Retired) 2012-06-19 08:50:18 PDT
Unless you have a contribution to make towards fixing this bug, please don't comment here.

We already know that this bug is serious:  It breaks Keychain Services Integration and parental controls, and probably also other programs that interact with the Keychain.

But it's an Apple bug, and moreover one that Apple has already fixed (in OS X 10.7).  So if you're really desperate for fix you'll need to upgrade OS X to 10.7 or higher.

If you have any complaints about this, please direct them to the company responsible for this bug -- to Apple.
Comment 20 Alex Keybl [:akeybl] 2012-06-19 08:59:08 PDT
We're tracking this bug for release of FF14.0/15.0, and understand that this is impacting the 2000 users of Keychain Services Integration. We'll try to find a fix for this either for the next release, or the following. Any help you can offer in resolution would be much appreciated.
Comment 21 Ovidiu 2012-06-19 09:02:40 PDT
@Steven: If it's Apple's fault, why doesn't Adium exhibit the problem? The latest version, 1.5.1, is also signed and works flawlessly on 10.6.8. http://trac.adium.im/wiki/AdiumVersionHistory

Couldn't you look at their build and apply the same signing to solve the problem?
Comment 22 Steven Michaud [:smichaud] (Retired) 2012-06-19 09:12:20 PDT
(In reply to comment #21)

This bug likely only effects apps signed with an app signing cert from Apple.  Though your app needs to be signed using this kind of cert to run on OS X 10.8, most apps are still signed using signing certs from some other source (not Apple).  I'd bet Adium is one of these.
Comment 23 Steven Michaud [:smichaud] (Retired) 2012-06-19 09:16:22 PDT
(Following up comment #22)

Oops, I was wrong.  Adium is now signed using an app signing cert from Apple.

I'll check the rules section of their CodeResources plist file when I get the chance.  Others working on this bug may want to do the same.
Comment 24 spinifer 2012-06-19 09:21:53 PDT
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
Comment 25 Steven Michaud [:smichaud] (Retired) 2012-06-19 09:26:28 PDT
spinifer, please attach a copy of Adium's CodeResources file.

By "attach" I mean use "Add an Attachment" above.  Don't just paste the file's contents into a comment.

In any signed app, the CodeResources file (a soft link) is in its Contents directory.
Comment 26 spinifer 2012-06-19 09:35:30 PDT
Created attachment 634470 [details]
Example of CodeResources that work on <10.7 from Adium 1.5.1
Comment 27 spinifer 2012-06-19 09:39:09 PDT
(Note: In Adium there's no softlink in Contents, the file was copied from _CodeSignature)
Comment 28 Steven Michaud [:smichaud] (Retired) 2012-06-19 09:45:18 PDT
(In reply to comment #26)

The "rules" section from that file is very small, so I'll just paste it in here.  I've currently *no* idea how or why it works ... but it's probably a good place to start.

	<key>rules</key>
	<dict>
		<key>^Resources/</key>
		<true/>
		<key>^Resources/.*\.lproj/</key>
		<dict>
			<key>optional</key>
			<true/>
			<key>weight</key>
			<real>1000</real>
		</dict>
		<key>^Resources/.*\.lproj/locversion.plist$</key>
		<dict>
			<key>omit</key>
			<true/>
			<key>weight</key>
			<real>1100</real>
		</dict>
		<key>^version.plist$</key>
		<true/>
	</dict>

(In reply to comment #27)

That's weird.  Maybe that's why the minimal "rules" section "works".

More grist for the mill.
Comment 29 Ben Hearsum (:bhearsum) 2012-06-19 09:48:09 PDT
Steven, I think there's additional things you can provide to codesign through command line arguments. Like:
> $ 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


I think these are what spinifer is talking about.
Comment 30 spinifer 2012-06-19 09:54:47 PDT
Check line 167 of Adium makefile: http://hg.adium.im/adium/file/705f147f6ea7/Release/Makefile

codesign --verbose --force --sign "Developer ID Application: Instant Messaging Freedom, Inc." --requirements "=designated => anchor apple generic  and identifier \"com.adiumX.adiumX\" and ((cert 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\" ))" $(ADIUM_DIR)/Adium.app
Comment 31 Steven Michaud [:smichaud] (Retired) 2012-06-19 10:01:56 PDT
Thanks, spinifer!

So as things now stand, we have two potential ways to work around Apple's bug:

1) Follow Julian's suggestion from comment #13
2) Use Adium as a model

Both will require further effort (in Adium's case, to figure out *why* what they do works).
Comment 32 Steven Michaud [:smichaud] (Retired) 2012-06-19 10:05:36 PDT
Actually Adium does what Julian suggests.

So we need to figure out why their stuff "works", and how much of it we actually need.

We also (of course) need to test it.
Comment 33 Julian Fitzell 2012-06-19 10:17:16 PDT
I believe the two suggestions are basically the same.

The suggestion from http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale is to:

1) Build on 10.8 using XCode 4.3 for Gatekeeper
2) Extract the DR using "codesign -d -r-" and save the "designate => ..." part in a text file
3) Compile the DR on 10.5.8 (or oldest version you want to support) using "csreq -r thetextfile.txt -b requirement.bin"
4) Embed that DR into your build using "codesign -r requirement.bin"

Adium has presumably done (1) and (2)--or an equivalent--to obtain the DR they are using (and note the example DR provided on the fetchworks page is logically equivalent to the one being used by Adium).
They seem to be avoiding the intermediate compilation step (perhaps they're doing all their compilation on 10.5.x anyway or have found that isn't actually needed for compatibility after all--this would need confirmation).
Rather than giving the compiled DR back to XCode seem to be replacing the signature after build using --force.

So, yeah... functionally equivalent really. In terms of why it works, perhaps you could clarify which part you're wondering about?
Comment 34 Ben Hearsum (:bhearsum) 2012-06-19 10:18:36 PDT
(In reply to Julian Fitzell from comment #33)
> I believe the two suggestions are basically the same.
> 
> The suggestion from
> http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale
> is to:
> 
> 1) Build on 10.8 using XCode 4.3 for Gatekeeper

This is a non-starter for us at this point. We don't have the resources to change our build platform at this time....
Comment 35 Steven Michaud [:smichaud] (Retired) 2012-06-19 10:20:20 PDT
If someone else gets to this before me:

If possible, we should put our additional requirements in the "rules" section of our CodeResources file (rather than just making them parameters to codesign).  That way everyone will easily be able to see what our signing requirements actually are.  And it'll be easier for us to keep track of them :-)
Comment 36 Julian Fitzell 2012-06-19 10:21:12 PDT
(In reply to Ben Hearsum [:bhearsum] from comment #34)
> (In reply to Julian Fitzell from comment #33)
> > I believe the two suggestions are basically the same.
> > 
> > The suggestion from
> > http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale
> > is to:
> > 
> > 1) Build on 10.8 using XCode 4.3 for Gatekeeper
> 
> This is a non-starter for us at this point. We don't have the resources to
> change our build platform at this time....

I believe this only needs to be done once to get the correct DR. But actually I think it's unnecessary since the ones Adium and Fetchworks are using are the same, and we know the correct OU for Mozilla's cert.

Just for completeness, though, could you clarify what versions of XCode and OS X *are* used in the FF build/signing process?
Comment 37 spinifer 2012-06-19 10:22:24 PDT
> 1) Build on 10.8 using XCode 4.3 for Gatekeeper

If that's the only way possible maybe in a week or so I can build a OSX 10.8 Virtual Machine (I'm a Parallels Desktop for Mac Beta Tester).
Comment 38 Steven Michaud [:smichaud] (Retired) 2012-06-19 10:22:56 PDT
(Following up comment #35)

> everyone will easily be able to see what our signing requirements actually are

What our *explicit* signing requirements are.

As opposed to those automatically generated by codesign.
Comment 39 Ben Hearsum (:bhearsum) 2012-06-19 10:25:15 PDT
(In reply to Julian Fitzell from comment #36)
> (In reply to Ben Hearsum [:bhearsum] from comment #34)
> > (In reply to Julian Fitzell from comment #33)
> > > I believe the two suggestions are basically the same.
> > > 
> > > The suggestion from
> > > http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale
> > > is to:
> > > 
> > > 1) Build on 10.8 using XCode 4.3 for Gatekeeper
> > 
> > This is a non-starter for us at this point. We don't have the resources to
> > change our build platform at this time....
> 
> I believe this only needs to be done once to get the correct DR. But
> actually I think it's unnecessary since the ones Adium and Fetchworks are
> using are the same, and we know the correct OU for Mozilla's cert.

Ah OK.

> Just for completeness, though, could you clarify what versions of XCode and
> OS X *are* used in the FF build/signing process?

We build on 10.7.2 with XCode 4.1.
We sign on 10.6.8 with XCode 4.2.
Comment 40 Julian Fitzell 2012-06-19 10:43:44 PDT
(In reply to Steven Michaud from comment #35)
> If someone else gets to this before me:
> 
> If possible, we should put our additional requirements in the "rules"
> section of our CodeResources file (rather than just making them parameters
> to codesign).  That way everyone will easily be able to see what our signing
> requirements actually are.  And it'll be easier for us to keep track of them
> :-)

As far as I can tell from reading the docs, I don't *think* this is possible. CodeResources only seems to specify rules for what is included in the application's Seal (i.e. files that aren't allowed to change) as well as the hashes for those files.

Requirements (which specify rules for identifying legitimate versions of dependencies) and in particular the Designated Requirement (which specifies rules for identifying other versions of the application itself) seem to only be specified on the command line to codesign.
Comment 41 Ben Hearsum (:bhearsum) 2012-06-19 10:58:16 PDT
(In reply to Julian Fitzell from comment #40)
> (In reply to Steven Michaud from comment #35)
> > If someone else gets to this before me:
> > 
> > If possible, we should put our additional requirements in the "rules"
> > section of our CodeResources file (rather than just making them parameters
> > to codesign).  That way everyone will easily be able to see what our signing
> > requirements actually are.  And it'll be easier for us to keep track of them
> > :-)
> 
> As far as I can tell from reading the docs, I don't *think* this is
> possible. CodeResources only seems to specify rules for what is included in
> the application's Seal (i.e. files that aren't allowed to change) as well as
> the hashes for those files.
> 
> Requirements (which specify rules for identifying legitimate versions of
> dependencies) and in particular the Designated Requirement (which specifies
> rules for identifying other versions of the application itself) seem to only
> be specified on the command line to codesign.

This kindof sucks from a maintainability standpoint, but it shouldn't make it any more hard for us to implement.
Comment 42 Julian Fitzell 2012-06-19 12:03:57 PDT
Created attachment 634529 [details]
Proposed DR

(In reply to Ben Hearsum [:bhearsum] from comment #41)
> (In reply to Julian Fitzell from comment #40)
> > Requirements (which specify rules for identifying legitimate versions of
> > dependencies) and in particular the Designated Requirement (which specifies
> > rules for identifying other versions of the application itself) seem to only
> > be specified on the command line to codesign.
> 
> This kindof sucks from a maintainability standpoint, but it shouldn't make
> it any more hard for us to implement.

They can go in a file, just not the CodeResources file. Ok, so I've just been testing the following command line, starting with a stock FF13 binary:

codesign --verbose --sign "Julian Test Certificate" --force --requirements requirement.txt --resource-rules=Firefox.app/Contents/CodeResources Firefox.app

The process seems to work fine, and I end up with a binary that now satisfies its DR (see output below). Obviously, I'm using a self-signed certificate here and had to add the clause 'or (certificate leaf[subject.O] = "Fitzell")' to the end of the file for testing, so someone would need to confirm with an Apple Developer cert. It would also be better to specify the DR in the initial codesign rather than resigning.

I think this demonstrates that we've correctly identified the source of the problem here, that specifying a DR can fix it, and that all you should need to do to the build process is add the "--requirements requirement.txt" parameter to the codesign invocation.

If someone would be willing to try running a developer build with that modification, I'm sure we'd be happy to test.


BEFORE RESIGNING:
~~~~~~~~~~~~~~~
$ codesign -vvvv Firefox.app
Firefox.app: valid on disk
Firefox.app: does not satisfy its designated Requirement

$ codesign -d -r- Firefox.app
Executable=/Users/julian/foo/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


AFTER RESIGNING:
~~~~~~~~~~~~~~
$ codesign -vvvv Firefox.app
Firefox.app: valid on disk
Firefox.app: satisfies its Designated Requirement

$ codesign -d -r- Firefox.app
Executable=/Users/julian/foo/Firefox.app/Contents/MacOS/firefox
designated => identifier "org.mozilla.firefox" and (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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] = VQ6ZEL8UD3 or certificate leaf[subject.O] = Fitzell)
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
Comment 43 Steven Michaud [:smichaud] (Retired) 2012-06-19 12:24:57 PDT
Julian:

Later this afternoon I'll try signing Firefox in the way you suggest, using my Apple-provided app signing cert.  I'll report my results here.

Please give as quick an easy way as you can suggest to test this copy of Firefox with Keychain Services Integration (which I've never used before).

Please also let us know if the copy of FF you signed worked properly with Keychain Services Integration :-)
Comment 44 Steven Michaud [:smichaud] (Retired) 2012-06-19 12:48:36 PDT
> --resource-rules=Firefox.app/Contents/CodeResources Firefox.app

Note that you *don't* want to to this.  Instead make a copy of CodeResources and edit out the "files" section.  We learned this the hard way :-)
Comment 45 Julian Fitzell 2012-06-19 12:51:17 PDT
Thanks for your help, Steven.

Honestly, if "codesign -vvvv Firefox.app" reports that the DR is satisfied, it should work fine with Keychain Services. The failing DR is the specific cause of our problem.

If you do want to test end to end though, keep in mind that it's going to be potentially modifying your system keychain, so if you want to be completely safe, create a test account on your OS X machine and run Firefox there. That will also make sure that FF is actually using the keychain and not just pulling your passwords out of its own database. The simplest test would be:

- create a new OS X account
- start firefox
- install the extension (latest is 1.1.3): https://addons.mozilla.org/en-US/firefox/addon/keychain-services-integration/
- restart firefox
- you'll be asked if you want to import your FF passwords into the keychain (say no, I guess)
- go to gmail.com (or anywhere that FF offers to save the password for should be fine)
- login
- when FF asks if you want to save the password, say yes
- run Keychain Access.app and make sure that an appropriate entry has been added to the keychain
- logout of gmail
- go to the login page again
- FF should fill in the name and password automatically and OS X should not ask you for permission (this is what is currently broken - when the DR fails, it asks for permission every time FF tries to look up the password)
- try logging in to make sure the password was correctly obtained

I just tested the self-signed binary I made now, and it works fine.
Comment 46 Julian Fitzell 2012-06-19 12:55:24 PDT
(In reply to Steven Michaud from comment #44)
> > --resource-rules=Firefox.app/Contents/CodeResources Firefox.app
> 
> Note that you *don't* want to to this.  Instead make a copy of CodeResources
> and edit out the "files" section.  We learned this the hard way :-)

Hm.. seemed to work but thanks for the warning. :) I only added that because otherwise I ended up with a much smaller seal after re-signing and thought that might be a problem. I didn't actually look into whether it was correct or not... just that the output of "codesign -d -v -r-" was the same.
Comment 47 Julian Fitzell 2012-06-19 13:16:22 PDT
(In reply to Steven Michaud from comment #43)
> Later this afternoon I'll try signing Firefox in the way you suggest, using
> my Apple-provided app signing cert.  I'll report my results here.

Probably goes without saying, but just to be sure, if you're using a different cert for signing, the OU in registration.txt will presumably need to be updated...
Comment 48 Steven Michaud [:smichaud] (Retired) 2012-06-19 14:15:33 PDT
Julian, I'm having trouble finding the field OID's quoted in your DR file in the Apple certs that are usually included in a signature (and are available using codesign -d --extract-certificates).

I've been using "openssl x509".  Do you have a better way to view the contents (especially the fields) of a cert?  Do you know how to do it using openssl x509?
Comment 49 Julian Fitzell 2012-06-19 14:27:19 PDT
They're probably visible in Keychain Access (my self-signed one is anyway) under Certificates in the bottom left pane?

Or, just poked around a bit and this seems to work for me:

openssl x509 -text -in filename -inform DER
Comment 50 Steven Michaud [:smichaud] (Retired) 2012-06-19 14:29:59 PDT
> openssl x509 -text -in filename -inform DER

That "works", but doesn't print out *any* of the OIDs from your DR for *any* of the certs I've looked at.

Yes, I'm being picky ... but that's my job :-)
Comment 51 Steven Michaud [:smichaud] (Retired) 2012-06-19 14:37:53 PDT
Oops, never mind.

I've been looking at the certs in Safari's signature ... which of course don't obey Apple's rules.  The certs in Firefox's current signature do include the OIDs specified for an app that's been signed with an app signing cert from Apple.
Comment 52 Julian Fitzell 2012-06-19 15:53:31 PDT
I'm on my way to bed, but one further comment based on something I just realized... For testing purposes, you can tell if the DR has been included in the signature or is being automatically generated on the running machine by running "codesign -d -v -r-" and checking if the "designated => ..." line is prefixed by a #.

If so, you are seeing a default DR; if not, it was specified when the app was signed.

Good luck and thanks again for looking into this.
Comment 53 Steven Michaud [:smichaud] (Retired) 2012-06-19 16:19:35 PDT
Julian, I've now run the test you suggested, and it worked!

I tested on OS X 10.6.8.

I tested with two copies of Firefox 13.0.1 (the current version) -- the standard distro and one that I'd signed myself, using attachment 634529 [details] (altered with the UID from my own Apple-provided signing cert) for --requirements and a copy of FF's CodeResources containing only its "rules" section for --resource-rules.

The "original" Firefox 13.0.1 failed as described in comment #3.  My newly signed FF 13.0.1 worked as expected -- with no extra prompts to "always allow" access to the Keychain.

For good measure I also tested parental controls (as per bug 763956).  They also worked as expected (with my newly signed Firefox 13.0.1).

Thanks for the help everyone's given here -- particularly Julian and spinifer.
Comment 54 Steven Michaud [:smichaud] (Retired) 2012-06-19 16:26:47 PDT
Comment on attachment 634529 [details]
Proposed DR

We probably don't need everything that's specified here.  We almost certainly won't need the part that applies to apps signed for the Mac App Store.

But none of the requirements specified for apps signed using an Apple-provided developer application signing cert should cause trouble -- at least for the lifetime of the signing cert we're currently using.  And as long as Apple doesn't remove or change the OIDs of the specified fields, we should also be fine using signing certs we get from them in the future.
Comment 55 Steven Michaud [:smichaud] (Retired) 2012-06-19 16:27:27 PDT
Ben, can I now pass this bug off to you? :-)
Comment 56 spinifer 2012-06-19 16:28:55 PDT
Great news, congratulations! Thanks for following this thru Steven and thanks Julian for providing the needed info.
Comment 57 Ben Hearsum (:bhearsum) 2012-06-20 06:24:29 PDT
(In reply to Steven Michaud from comment #55)
> Ben, can I now pass this bug off to you? :-)

Yes, I think I can take it from here! I should be able to get this landed on nightly/aurora/beta sometime next week.

Thank you, spinifer and Julian for all your help - it's been invaluable.
Comment 58 Ben Hearsum (:bhearsum) 2012-06-20 07:39:22 PDT
(In reply to Steven Michaud from comment #55)
> Ben, can I now pass this bug off to you? :-)

Oh one more thing: could you send a build off to QA so they can run through some spot checks?
Comment 59 Steven Michaud [:smichaud] (Retired) 2012-06-20 07:57:09 PDT
(In reply to comment #58)

You mean the build of FF 13.0.1 that I signed myself?
Comment 60 Ben Hearsum (:bhearsum) 2012-06-20 08:04:53 PDT
(In reply to Steven Michaud from comment #59)
> (In reply to comment #58)
> 
> You mean the build of FF 13.0.1 that I signed myself?

Yeah
Comment 61 Steven Michaud [:smichaud] (Retired) 2012-06-20 08:20:29 PDT
Here's the build of FF 13.0.1 that I signed myself, and with which I did the tests I described in comment #53:

http://people.mozilla.com/~stmichaud/SigningTests/Firefox%2013.0.1-signed-with-requirements.dmg

QA, please test with it as you think appropriate.
Comment 62 Steven Michaud [:smichaud] (Retired) 2012-06-20 15:21:04 PDT
Here's a summary of the Apple bug that causes this bug (bug 765271),
as I currently understand it:

It's partly a bug in old versions of Apple's codesign utility, and
partly a bug in how versions of OS X before 10.7 evaluate a signed
app's designated requirements.

1) When old versions of codesign are used to sign an app with a code
   signing cert from Apple, the designated requirements automatically
   generated are considered by OS X 10.6 and earlier (somehow) not to
   match the apps that have been signed.

   As a result these old versions of codesign return the following
   error when told to verify these app signatures (even ones that
   they've just created):

   [/path/to/application]: does not satisfy its designated Requirement

   The versions of codesign that come with XCode 3.2.X, 4.1 and 4.2
   have this problem.  The versions of codesign that come with XCode
   4.3.X and up don't.  (XCode 4.3.X is only available for OS X 10.7
   and up.)

   Even old versions of codesign don't have this problem using signing
   certs that don't come from Apple (whose root CA is a non-Apple CA).
   In that case they automatically generate designated requirements in
   the following format:

   designated => identifier "org.your.app" and
     anchor root = H"62f167aaad099667c327283797a75c8767cac473"

2) Even apps whose signatures are "incorrect" as per the above
   description work just fine on OS X 10.7 and up.  Specifically, they
   have no problems interacting with the Keychain.

   This shows that Apple doesn't believe there's any benefit to using
   stricter designated requirements for apps signed using code signing
   certs from Apple.  In fact I think this is true.

The designated requirements in attachment 634529 [details] have the format of
those automatically generated by the version of codesign that comes
with XCode 4.4 and up (currently only available on OS X 10.8).  We're
almost certainly safe using this format.

But the format automatically generated by the version of codesign that
comes with XCode 4.3 works just as well on old versions of OS X (10.6
and 10.5), and is quite different:

designated => identifier "org.your.app" and anchor apple

We'd probably also be safe using this format.
Comment 63 Steven Michaud [:smichaud] (Retired) 2012-06-20 15:46:05 PDT
(Following up comment #62)

> But the format automatically generated by the version of codesign
> that comes with XCode 4.3 works just as well on old versions of OS X
> (10.6 and 10.5), and is quite different:
>
> designated => identifier "org.your.app" and anchor apple
>
> We'd probably also be safe using this format.

Oops, this isn't quite right.  Firefox 13.0.1's "bad" signature also
has this designated requirement.

The difference between the "good" requirements automatically generated
by codesign from XCode 4.3.X (on OS X 10.7) and the "bad" requirements
generated by codesign from older versions of XCode (on OS X 10.6)
isn't in the designated requirments at all.  It's in the list of
"library" requirments:

Automatically generated by codesign from XCode 4.3.2 (on OS X 10.7.4):

library => identifier "com.apple.Cocoa" and anchor apple
  or identifier "com.apple.ExceptionHandling" and anchor apple
  or identifier "libstdc++.6" and anchor apple
  or identifier "libSystem.B" and anchor apple
  or identifier "libSystem.B" and anchor apple
  or identifier "com.apple.CoreFoundation" and anchor apple
  or identifier "com.apple.ApplicationServices" and anchor apple

Automatically generated by codesign from XCode 3.2.6 (on OS X 10.6.8):

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

> We'd probably also be safe using this format.

Actually we wouldn't be.
Comment 64 Julian Fitzell 2012-06-20 16:01:41 PDT
(In reply to Steven Michaud from comment #62)
> But the format automatically generated by the version of codesign that
> comes with XCode 4.3 works just as well on old versions of OS X (10.6
> and 10.5), and is quite different:
> 
> designated => identifier "org.your.app" and anchor apple
> 
> We'd probably also be safe using this format.

"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"
(From: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/RequirementLang/RequirementLang.html)
Comment 65 Julian Fitzell 2012-06-20 16:03:59 PDT
(In reply to Julian Fitzell from comment #64)
> (In reply to Steven Michaud from comment #62)
> > But the format automatically generated by the version of codesign that
> > comes with XCode 4.3 works just as well on old versions of OS X (10.6
> > and 10.5), and is quite different:
> > 
> > designated => identifier "org.your.app" and anchor apple
> > 
> > We'd probably also be safe using this format.
> 
> "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"
> (From:
> https://developer.apple.com/library/mac/#documentation/Security/Conceptual/
> CodeSigningGuide/RequirementLang/RequirementLang.html)

But as I said above, that would allow *anyone* with an apple developer ID to sign versions of Firefox...
Comment 66 Julian Fitzell 2012-06-20 16:08:45 PDT
(In reply to Steven Michaud from comment #63)
> (Following up comment #62)
> 
> > But the format automatically generated by the version of codesign
> > that comes with XCode 4.3 works just as well on old versions of OS X
> > (10.6 and 10.5), and is quite different:
> >
> > designated => identifier "org.your.app" and anchor apple
> >
> > We'd probably also be safe using this format.
> 
> Oops, this isn't quite right.  Firefox 13.0.1's "bad" signature also
> has this designated requirement.

Being pedantic (I think that's necessary here for clarity) but FF13 binaries don't contain *any* DR. You can tell because "codesign -d -r- -v" prepends a '#' in front of the "designated => ..." line

From the codesign man page:

"If the code does not contain an explicit designated requirement, the implied one will be retrieved and written out as a source comment."
Comment 67 Steven Michaud [:smichaud] (Retired) 2012-06-20 16:11:42 PDT
> But as I said above, that would allow *anyone* with an apple
> developer ID to sign versions of Firefox...

I don't see the problem with this. 

Anyone with *any* kind of valid signing	cert can sign Firefox (or any
other app).  There's nothing wrong with this.

There'd only be a problem if someone could alter the app in a
significant way without breaking signature verification.
Comment 68 Steven Michaud [:smichaud] (Retired) 2012-06-20 16:13:44 PDT
(In reply to comment #66)

In comment #62 and following I'm talking about automatically generated designated requirements (and the problems with them), not about explicitly generated designated requirements.
Comment 69 Julian Fitzell 2012-06-20 16:23:17 PDT
(In reply to Steven Michaud from comment #67)
> > But as I said above, that would allow *anyone* with an apple
> > developer ID to sign versions of Firefox...
> 
> I don't see the problem with this. 
> 
> Anyone with *any* kind of valid signing	cert can sign Firefox (or any
> other app).  There's nothing wrong with this.

I'd disagree. I choose to grant Firefox access to certain passwords in my keychain because I have chosen to trust Mozilla not to distribute a product that will access those passwords and, say, send them over to a hacker somewhere. Whether that's a wise choice or not, given third party extensions and so on, is another issue of course, but not the point here.

I do *not* want any random person to be able to create an application, give it the id "org.mozilla.firefox", sign it themselves, and have access to those passwords. Similarly, if I'm a parent and I set up Access Control to allow my child to run Firefox, I don't want them to be able to run applications that they or others have made to look like firefox and signed for themselves.

The whole point of the designated requirement is to specify a set of rules that includes *only* legitimate versions of your own software.
Comment 70 Steven Michaud [:smichaud] (Retired) 2012-06-20 16:30:13 PDT
I see your point.  But the solution to your problem isn't what you think it is.

There's no way to sign an app (using any number of designated requirements) that will prevent someone from re-signing it with a different signature (completely removing the previous signature).

There *are* ways for vendors to identify apps as coming from *them* -- which include asking users to look for a particular signature.
Comment 71 Julian Fitzell 2012-06-20 16:51:30 PDT
Sure, they can resign the app. But the keychain records the DR when you click "Always allow". At that point I am asking the system to check for a particular signature for me whenever an application tries to access that password.

Any app that meets the DR will then have access to those passwords without the user granting permission. Any app that does not meet the DR will result in the user being prompted.

The DR is a distinct entity from the signature and the entire point of it is for the developer to tell the operating system how to identify legitimate versions of the *same* application. This allows the OS to do exactly what you are saying a user could do manually. But it only works if the DR is correctly specified.

I don't care if someone resigns Firefox. What I don't want is for the operating system to think it's still the same Firefox I granted permission to.
Comment 72 Steven Michaud [:smichaud] (Retired) 2012-06-20 16:57:57 PDT
So you're saying that the DR plays a special role *in Keychain access*.

I don't disbelieve you.  But I'd be curious to know how you came to this conclusion.

And, to avoid cluttering up this bug, it's probably best just to paste in a few URLs (pointing to relevant Apple docs and/or other discussions).

In any case, I agree that it's best to make how we sign Firefox conform as closely as possible to Apple's current standard practice.  Which if the behavior of codesign on 10.8 is any guide, means we should use your DR from attachment 634529 [details].
Comment 73 Julian Fitzell 2012-06-20 17:11:22 PDT
(In reply to Steven Michaud from comment #72)
> So you're saying that the DR plays a special role *in Keychain access*.
> 
> I don't disbelieve you.  But I'd be curious to know how you came to this
> conclusion.

I guess it would be more accurate to say that this is the only role that DRs play. But it's not just Keychain access: Parental Control and Application Firewall certainly do the same thing. I'm not sure if anything else in the system does currently, but they certainly could.

I think the best sources are this section of the Code Signing Guide:
http://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html#//apple_ref/doc/uid/TP40005929-CH3-SW2

and the second paragraph of this section:
http://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html#//apple_ref/doc/uid/TP40005929-CH3-SW5

(and calling it a night again here, so I'll sign off now)
Comment 74 Ben Hearsum (:bhearsum) 2012-06-26 07:28:13 PDT
I started poking at this today and it mostly worked fine with the following command:
codesign --resource-rules /Volumes/Nightly/FirefoxNightly.app/Contents/_CodeSignature/CodeResources -s "Mozilla" --keychain ~/instances/rel-key-signing-server-2/secrets/dmg/signing.keychain -f -v --requirement '=designated =>  identifier "org.mozilla.nightly" and ( (anchor apple generic and    certificate leaf[field.1.2.840.113635.100.6.1.9] ) or (anchor apple generic and    certificate 1[field.1.2.840.113635.100.6.2.6]  and    certificate leaf[field.1.2.840.113635.100.6.1.13] and    certificate leaf[subject.OU] = "43AQ936H96"))' /Volumes/Nightly/FirefoxNightly.app


Note that the identifier is "org.mozilla.nightly" instead of "org.mozilla.firefox", because I'm signing a nightly. I've put this build here for testing: http://people.mozilla.com/~bhearsum/samplebuilds/

Steven, Spinifer, Julian - can you all have a look at it and see if it stands up to your testing? I've sent the http auth info in e-mail.

If the build looks fine I'll need to figure out how to cope with the different identifiers for different branches, but then we're home free!
Comment 75 Steven Michaud [:smichaud] (Retired) 2012-06-26 09:45:23 PDT
Ben, I tested your build on OS X 10.6.8 and saw no problems.

I tested with Julian's STR from comment #45, and also with the STR for bug 763956.

For good measure I tried switching back and forth between the test build and today's mozilla-central nightly.  The results I got with Keychain Services Integration were expected:  I kept being prompted to "allow always" with today's mozilla-central nightly.  Then when I went back to the test build I got prompted again, but just once.  This shows that the Apple Keychain saw them as two different apps.

But the results I got testing parental controls were a bit disturbing:  Once I'd clicked "always allow" for the test build, I was never prompted again to allow either build.  Presumably parental controls (in its use of the keychain) can't tell the difference between the two builds.

Yet another Apple bug.  And presumably one about which we can't do anything.
Comment 76 spinifer 2012-06-26 09:48:22 PDT
Thanks Ben,

Testing on OS X 10.6.8...

Running the nightly now, Comment #3 Testcase passed, once I 'Always Allow' it doesn't ask for again for that password, this is the correct behaviour. Only test missing is, if after upgrading to a new version it doesn't prompt again.

The results from the command prompt are also as expected:

$ codesign -vv /Applications/FirefoxNightly.app/
/Applications/FirefoxNightly.app/: valid on disk
/Applications/FirefoxNightly.app/: satisfies its Designated Requirement

$ codesign -d -r- /Applications/FirefoxNightly.app/
Executable=/Applications/FirefoxNightly.app/Contents/MacOS/firefox
designated => identifier "org.mozilla.nightly" and (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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")
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
Comment 77 Ben Hearsum (:bhearsum) 2012-06-26 10:24:30 PDT
Okay, so based on the last two comments it sounds like the codesign command I used is correct, and there's no reason I shouldn't get it into the automation?
Comment 78 Julian Fitzell 2012-06-26 10:34:56 PDT
Sounds like it's great, but I'll do a quick check now for completeness sake...
Comment 79 Steven Michaud [:smichaud] (Retired) 2012-06-26 10:54:25 PDT
I just tested Ben's build on the latest DP of Mountain Lion (Build 12A256), which came out in the last couple of days.  It ran as expected (I saw the quarantine dialog instead of the "unknown developer" dialog).

As far as I'm concerned, Ben, you can go ahead and land the patch!
Comment 80 Julian Fitzell 2012-06-26 11:21:16 PDT
Ok, I've tested and all looks good.

1) The test build behaves as expected for:
 * Keychain access,
 * codesign DR verification on the command line, and
 * (for good measure even though I've never used it before) Parental Control.

I then tested using the June 24 nightly (with a non-validating DR but, crucially, a valid signature and different version number).

2) The June 24 nightly was able to access keychain items to which the test build had been granted access, which is expected. I believe this addresses the missing test case mentioned in Comment 76.

3) As before, any attempts to "Allow all" for the June 24 nightly continued to be ignored and prompts displayed each time a page is reloaded. This is expected since the June 24 nightly does not satisfy its own DR.

4) Attempts to run the June 24 nightly under Parental Control were successful. Contrary to the suggestion in Comment 75, this is expected behaviour. Neither build satisfies the DR of the June 24 nightly, so attempts to grant access to it will not work and prompts will continue. *Both* builds satisfy the DR of the test build, however, so granting access to the test build will allow both builds to run.

As far as I'm concerned, that's expected behaviour on all tests I can think of.

Apologies for not knowing the details of the build schedule, but where is this likely to land at this point?
Comment 81 Julian Fitzell 2012-06-26 11:26:16 PDT
Oh, sorry, one possible problem I did notice:

For the June 26 nightly off the website:
$ codesign -d -v -r- /Volumes/Nightly\ 2/FirefoxNightly.app
... [snipped] ...
Sealed Resources rules=9 files=100
... [snipped] ...

For the test build:
$ codesign -d -v -r- /Applications/FirefoxNightly.app
... [snipped] ...
Sealed Resources rules=4 files=4
... [snipped] ...
Comment 82 spinifer 2012-06-26 11:40:04 PDT
(In reply to Julian Fitzell from comment #81)
> Oh, sorry, one possible problem I did notice:
> 
> For the June 26 nightly off the website:
> $ codesign -d -v -r- /Volumes/Nightly\ 2/FirefoxNightly.app
> ... [snipped] ...
> Sealed Resources rules=9 files=100
> ... [snipped] ...
> 
> For the test build:
> $ codesign -d -v -r- /Applications/FirefoxNightly.app
> ... [snipped] ...
> Sealed Resources rules=4 files=4
> ... [snipped] ...

Ugh, you're right, the CodeResources file is minimal and there are 2 copies of it, in Contents and _CodeSignature instead of the first being just an alias/symlink of the second.
Comment 83 Ben Hearsum (:bhearsum) 2012-06-26 11:42:19 PDT
Whoops, I may have screwed that part up. We can't use symlinks because they don't work with our updater. However, we copy the one from _CodeSignature to Contents after signing, to make sure they are the same. I'll double check that I did that right shortly....
Comment 84 Ben Hearsum (:bhearsum) 2012-06-26 12:04:23 PDT
(In reply to spinifer from comment #82)
> (In reply to Julian Fitzell from comment #81)
> > Oh, sorry, one possible problem I did notice:
> > 
> > For the June 26 nightly off the website:
> > $ codesign -d -v -r- /Volumes/Nightly\ 2/FirefoxNightly.app
> > ... [snipped] ...
> > Sealed Resources rules=9 files=100
> > ... [snipped] ...
> > 
> > For the test build:
> > $ codesign -d -v -r- /Applications/FirefoxNightly.app
> > ... [snipped] ...
> > Sealed Resources rules=4 files=4
> > ... [snipped] ...
> 
> Ugh, you're right, the CodeResources file is minimal and there are 2 copies
> of it, in Contents and _CodeSignature instead of the first being just an
> alias/symlink of the second.

Indeed, the CodeResources in the test build is all messed up. This is just a manual signing screw-up and isn't an issue in production. I'll fix up the build and repost it with a proper CodeResources.
Comment 85 Ben Hearsum (:bhearsum) 2012-06-26 12:11:08 PDT
I just threw an updated build, with a proper CodeResources file up at http://people.mozilla.com/~bhearsum/samplebuilds/signed2.dmg

If you're curious about why we have to make a copy of it rather than symlinking there's more info here: https://bugzilla.mozilla.org/show_bug.cgi?id=758644. Be assured that all automated builds will have matching, proper copies though -- the previous test build was just a manual screw-up.
Comment 86 Julian Fitzell 2012-06-26 13:02:53 PDT
Tested the new build very quickly and confirm that:
- the resources appear correct in "codesign -d -v -r-"
- the new build still has access to keychain items approved for the first test build
Comment 87 spinifer 2012-06-26 13:24:39 PDT
(In reply to Julian Fitzell from comment #86)
> Tested the new build very quickly and confirm that:
> - the resources appear correct in "codesign -d -v -r-"
> - the new build still has access to keychain items approved for the first
> test build

Yep, I confirm this.
Comment 88 Ben Hearsum (:bhearsum) 2012-06-29 06:16:05 PDT
OK, I think I have the automation bits for this ready. The resulting build looks fine w.r.t. codesign when testing on 10.6 w/ 4.1:
r5-mini-005:Nightly cltbld$ codesign -vv FirefoxNightly.app/
FirefoxNightly.app/: valid on disk
FirefoxNightly.app/: satisfies its Designated Requirement
r5-mini-005:Nightly cltbld$ codesign -d -r- FirefoxNightly.app/
Executable=/Volumes/Nightly/FirefoxNightly.app/Contents/MacOS/firefox
designated => identifier "org.mozilla.nightly" and (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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")
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

If anyone wants to have a look at it I've put it up here: http://people.mozilla.com/~bhearsum/samplebuilds/nightly-signed-automation.dmg.
Comment 89 Ben Hearsum (:bhearsum) 2012-06-29 06:23:58 PDT
Created attachment 637881 [details] [diff] [review]
update signing server to support designated requirements

This patch adds the --requirement specified in the earlier attachment to the codesign command used to sign mac builds. It's a little bit tricky, because we need to pull the CFBundleIdentifier at signing time, because it's different between Firefox/Thunderbird as well as between Nightly/Aurora/Beta+Release. The subject OU is also different between Nightly+Release and dep builds -- Apple has a random looking hex string that is consistent between both of our Developer IDs, and the self-signed cert we use for dep builds uses something else.

Alex/Lukas, I'm asking for approval on all branches for this patch because there's no way we can enable it on a per-branch basis. I believe the risk is low based on Steven's, Julian's, and spinifer's testing. If we land this before the next Beta we can get a couple of weeks of testing before the Firefox 14 release.
Comment 90 Ben Hearsum (:bhearsum) 2012-06-29 06:26:41 PDT
Created attachment 637883 [details] [diff] [review]
puppet manifest updates

Adds mac_cert_subject_ou to signscript.ini, and updates the test tarball for dmg signing to include CFBundleIdentifier in Info.plist.
Comment 91 spinifer 2012-06-29 07:24:00 PDT
In my opinion, the risk is minimal to none, as the possible problems of incompatible signing are already being experienced (this bug) on <10.7.
Comment 92 Steven Michaud [:smichaud] (Retired) 2012-06-29 08:40:57 PDT
> http://people.mozilla.com/~bhearsum/samplebuilds/nightly-signed-automation.dmg

For what it's worth, I just tested running this on OS X 10.8 (Build 12A256, Apple's latest), and had no problems.
Comment 93 Lukas Blakk [:lsblakk] use ?needinfo 2012-06-29 10:52:33 PDT
Comment on attachment 637881 [details] [diff] [review]
update signing server to support designated requirements

approving for aurora/beta - not approving for esr right now since we're not signing on esr yet, i'll set tracking for 13 on this so we can consider it should a need for a respin come up.
Comment 94 Ben Hearsum (:bhearsum) 2012-06-29 12:21:08 PDT
(In reply to Lukas Blakk [:lsblakk] from comment #93)
> Comment on attachment 637881 [details] [diff] [review]
> update signing server to support designated requirements
> 
> approving for aurora/beta - not approving for esr right now since we're not
> signing on esr yet, i'll set tracking for 13 on this so we can consider it
> should a need for a respin come up.

To be clear: once this is landed, *all* mac builds on *all* branches (that are signed) will get this. You're right that it doesn't affect ESR because we're not signing there yet. But any Firefox 13 chemspills/respins would get it, too. If that's not OK we'll have to look at a different strategy for landing this.
Comment 95 spinifer 2012-06-29 14:08:47 PDT
I don't know if I can help with this, but in my opinion Firefox Stable is already being shipped with incompatible signing, what could've gone wrong with it is already being felt (Keychain Access, Parental Controls), no point in holding this for the Stable branch if there wasn't such restriction when signing was introduced (albeit, two wrongs don't make a right).
Comment 96 Ben Hearsum (:bhearsum) 2012-06-29 14:43:44 PDT
(In reply to spinifer from comment #95)
> I don't know if I can help with this, but in my opinion Firefox Stable is
> already being shipped with incompatible signing, what could've gone wrong
> with it is already being felt (Keychain Access, Parental Controls), no point
> in holding this for the Stable branch if there wasn't such restriction when
> signing was introduced (albeit, two wrongs don't make a right).

Yeah, I agree completely. The only thing to debate (IMO) is whether or not this patch is the risk of this causing more problems. We had to enable signing when 13.0 shipped, to make sure we were ready in case 10.8 was released before 14.0, otherwise it wouldn't have been rushed in.
Comment 97 Virgil Dicu [:virgil] [QA] 2012-07-02 08:21:46 PDT
Is there still need for qawanted here? I understand that testing has already been concluded on the build from comment 74. 

Will the steps in comment 3 suffice for verification or are there any other guidelines we could use?
Comment 98 Alex Keybl [:akeybl] 2012-07-02 16:13:43 PDT
Comment on attachment 637881 [details] [diff] [review]
update signing server to support designated requirements

[Triage Comment]
Minusing for release since a 13.0.2 is unlikely at this point and this likely wouldn't meet chemspill criteria, but the ESR nom for when we figure out what to do about signing those builds.
Comment 99 Ben Hearsum (:bhearsum) 2012-07-03 04:48:58 PDT
(In reply to Alex Keybl [:akeybl] from comment #98)
> Comment on attachment 637881 [details] [diff] [review]
> update signing server to support designated requirements
> 
> [Triage Comment]
> Minusing for release since a 13.0.2 is unlikely at this point and this
> likely wouldn't meet chemspill criteria, but the ESR nom for when we figure
> out what to do about signing those builds.

I probably shouldn't have used all of these flags, as it seems to be causing confusion. The patch I need to land is a patch to the signing server code -- not to the source repositories. I can land it now and it would effect all Mac builds signed from this point on (which is to say, any Mac builds produced anywhere, except for ESR). If we spin a 13.0.2 we could disable the patch temporarily in order to get it built without taking this. If that's OK, please let me know ASAP so I can get it landed today.
Comment 100 Alex Keybl [:akeybl] 2012-07-03 11:24:31 PDT
(In reply to Ben Hearsum [:bhearsum] from comment #99)
> I probably shouldn't have used all of these flags, as it seems to be causing
> confusion. The patch I need to land is a patch to the signing server code --
> not to the source repositories. I can land it now and it would effect all
> Mac builds signed from this point on (which is to say, any Mac builds
> produced anywhere, except for ESR). If we spin a 13.0.2 we could disable the
> patch temporarily in order to get it built without taking this. If that's
> OK, please let me know ASAP so I can get it landed today.

Ah I see - yep, that sounds like a fine plan. I'll approve for all branches then to try to remove some confusion.
Comment 101 Ben Hearsum (:bhearsum) 2012-07-03 12:23:44 PDT
Comment on attachment 637883 [details] [diff] [review]
puppet manifest updates

Updated master-puppet1.
Comment 102 Ben Hearsum (:bhearsum) 2012-07-03 12:25:16 PDT
Comment on attachment 637881 [details] [diff] [review]
update signing server to support designated requirements

Code is all pushed. I need to wait for the mac servers to sync up with Puppet, and then restart the instances on them. After that, we'll be done here!
Comment 103 Ben Hearsum (:bhearsum) 2012-07-03 12:55:28 PDT
Ok, all the signing server instances have been restarted for this change. From here on out, all signed mac builds should be signed with the DR we want. I'll link to some builds shortly if anyone wants to verify, and Firefox 14.0 Beta 11 will be released later this week and should be signed properly.

Thanks to everyone who helped out here (Julian, spinifer, and Steven in particular) - this was truly a team effort.
Comment 104 Ben Hearsum (:bhearsum) 2012-07-03 15:19:12 PDT
Here's a build which I believe is working fine now, and came out of our normal automation (as opposed to the one-off signings I did in earlier comments):
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1341349860/firefox-16.0a1.en-US.mac.dmg
It passes codesign -vv on a 10.6 machine for me:
talos-r4-snow-023:Nightly cltbld$ codesign -vv FirefoxNightly.app/
FirefoxNightly.app/: valid on disk
FirefoxNightly.app/: satisfies its Designated Requirement



And on a sidenote, I think this bug is an awesome example of why our community is awesome and matters. I blogged about it: http://blog.mozilla.org/bhearsum/archives/317
Comment 105 Julian Fitzell 2012-07-03 16:17:28 PDT
Quick test here suggests everything's fine. Having signed builds working will be a big win now since it removes the needed to re-authorize all your passwords every time you upgrade Firefox. And great for users of Parental Control as well (someone should update Issue 763956 as well).

Agree it's a great example... having made similar attempts to provide similarly detailed bug reports to... let's just say other organizations... I can tell you they've gone exactly nowhere. It's nice to at least have a hope of getting things fixed. :) Thanks for your help.
Comment 106 spinifer 2012-07-05 04:20:59 PDT
I'm on the Beta branch, I'll be waiting for beta 11 to come my way then.

Thank you all (Steven, Ben, Julian) for the effort and knowledge put into solving this. (:
Comment 107 Ben Hearsum (:bhearsum) 2012-07-05 04:34:42 PDT
Beta 11 should be coming your way through the normal channels today or tomorrow. If you want to give it a try ahead of time you can grab it here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/14.0b11-candidates/build1/mac/en-US/Firefox%2014.0b11.dmg
Comment 108 elasmo 2012-07-08 12:11:08 PDT
(In reply to Ben Hearsum [:bhearsum] from comment #107)
> Beta 11 should be coming your way through the normal channels today or
> tomorrow.

I have installed 14.0b11 on SL and the prompt for key chain access is no longer appearing. Codesign output:
$ codesign -vvv /Applications/Firefox.app/
/Applications/Firefox.app/: valid on disk
/Applications/Firefox.app/: satisfies its Designated Requirement

My problem: I'm also having the same issue with Thunderbird (re-prompting for key chain access all the time, Keychain Services Integration add-on). Will this also be fixed for Thunderbird once a new Thunderbird beta is out or does it require a new bug?

BTW: The error message seems to be somewhat different (Thunderbird 13.0.1):
$ codesign -vvv /Applications/Thunderbird.app
/Applications/Thunderbird.app: a sealed resource is missing or invalid
/Applications/Thunderbird.app/Contents/MacOS/libwidget.rsrc: resource added
/Applications/Thunderbird.app/Contents/MacOS/libxpcom_core.dylib: resource added
/Applications/Thunderbird.app/Contents/MacOS/modules/autoconfigUtils.jsm: resource added
/Applications/Thunderbird.app/Contents/MacOS/res/broken-image.png: resource added
/Applications/Thunderbird.app/Contents/MacOS/res/loading-image.png: resource added
/Applications/Thunderbird.app/Contents/MacOS/run-mozilla.sh: resource added
Comment 109 spinifer 2012-07-08 13:00:32 PDT
Upgraded to b11 yesterday and everything is going smoothly, the prompts are gone once 'Always Allow' has been selected.

elasmo,

I don't use Thunderbird on OSX but maybe I can help a little, the codesign message appears to be related to files existing inside the app bundle that aren't listed in 'CodeResources'.

I suggest you (re)download 13.0.1 and replace the existing Thunderbird.app and see if the codesign message still gives teh same error, if it still does than this means the CodeResources for Thunderbird is not correct and Mozilla devs should have a look.
Comment 110 Ben Hearsum (:bhearsum) 2012-07-09 05:11:34 PDT
(In reply to elasmo from comment #108)
> (In reply to Ben Hearsum [:bhearsum] from comment #107)
> > Beta 11 should be coming your way through the normal channels today or
> > tomorrow.
> 
> I have installed 14.0b11 on SL and the prompt for key chain access is no
> longer appearing. Codesign output:
> $ codesign -vvv /Applications/Firefox.app/
> /Applications/Firefox.app/: valid on disk
> /Applications/Firefox.app/: satisfies its Designated Requirement
> 
> My problem: I'm also having the same issue with Thunderbird (re-prompting
> for key chain access all the time, Keychain Services Integration add-on).
> Will this also be fixed for Thunderbird once a new Thunderbird beta is out
> or does it require a new bug?
> 
> BTW: The error message seems to be somewhat different (Thunderbird 13.0.1):
> $ codesign -vvv /Applications/Thunderbird.app
> /Applications/Thunderbird.app: a sealed resource is missing or invalid
> /Applications/Thunderbird.app/Contents/MacOS/libwidget.rsrc: resource added
> /Applications/Thunderbird.app/Contents/MacOS/libxpcom_core.dylib: resource
> added
> /Applications/Thunderbird.app/Contents/MacOS/modules/autoconfigUtils.jsm:
> resource added
> /Applications/Thunderbird.app/Contents/MacOS/res/broken-image.png: resource
> added
> /Applications/Thunderbird.app/Contents/MacOS/res/loading-image.png: resource
> added
> /Applications/Thunderbird.app/Contents/MacOS/run-mozilla.sh: resource added

I can't repro this on 10.7, which makes me think your Thunderbird.app is locally modified in some way. Where did you get it from? Can you try downloading it again (http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/13.0.1/mac/en-US/Thunderbird%2013.0.1.dmg) and diffing it against this one? I filed bug 772025 on this, so let's take discussion there.
Comment 111 Steven Michaud [:smichaud] (Retired) 2012-07-09 09:17:42 PDT
Another thought:

Elasmo's problem might have been caused by copying a new version of Thunderbird over an older version.

So elasmo, please try deleting (or renaming) the Thunderbird build you've been testing with, then dragging a new copy out of the dmg file you downloaded.
Comment 112 elasmo 2012-07-09 11:44:41 PDT
(In reply to Steven Michaud from comment #111)
> So elasmo, please try deleting (or renaming) the Thunderbird build you've
> been testing with, then dragging a new copy out of the dmg file you
> downloaded.

Thx for the hints. Summary: It really seems to be the signing problem as well. At least the new version does not fix the problem. I have added further information to bug 772025 (maybe you could add a dependency to this bug).
Comment 113 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-07-10 14:02:31 PDT
Is there anything left for QA to do on this bug, apart from verifying this bug is fixed? Speaking of which, is there a test to verify this is fixed? Apologies if it's already mentioned but I find this bug hard to follow.
Comment 114 spinifer 2012-07-10 14:05:46 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #113)
> Is there anything left for QA to do on this bug, apart from verifying this
> bug is fixed? Speaking of which, is there a test to verify this is fixed?
> Apologies if it's already mentioned but I find this bug hard to follow.

See Comment #3. :)
Comment 115 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-07-10 14:16:17 PDT
If all we need to do is verify this fixed with comment 3 then qawanted is no longer needed. We track verification work with the tracking/status flags.
Comment 116 spinifer 2012-07-11 15:13:30 PDT
Update from beta 11 to beta 12, everything's working fine, access to previously allowed keychain items is maintained.
Comment 117 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-07-11 15:21:00 PDT
Thanks spinifer, calling this verified for Firefox 14. Would you be able to retest this with the Aurora builds?
Comment 118 spinifer 2012-07-12 07:27:26 PDT
Well, I might, if no one else is up for it, but I only have Snow Leopard on my own machine, I have Lion and ML Virtual Machines.
And I don't use Aurora on SL, I can install it alongside the Beta, since it uses the same certificate it should have the same accesses granted to it, although I rather not have Aurora mess any of my Firefox current settings.
Comment 119 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-07-12 10:22:49 PDT
Starting any version of Firefox with -P will allow you to create a test profile and not mess your user profile. 

Firefox.app/Contents/MacOS/firefox -P -no-remote will let you run two instances of Firefox side-by-side on different profiles.
Comment 120 spinifer 2012-07-23 09:05:46 PDT
Beta moved from 14 to 15, everything still working correctly after upgrade to 15.
Comment 121 Vlad [QA] 2012-08-03 05:19:58 PDT
I have verified this using the steps from comment3 on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0
and the paswords are remembered as expected.
Comment 122 Alex Keybl [:akeybl] 2012-09-13 16:17:14 PDT
Comment on attachment 637881 [details] [diff] [review]
update signing server to support designated requirements

Waiting for ESR17 to roll this out.

Note You need to log in before you can comment on or make changes to this bug.