Closed Bug 772025 Opened 13 years ago Closed 13 years ago

Thunderbird's CodeResources file may not be quite right

Categories

(Thunderbird :: Build Config, defect)

13 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bhearsum, Unassigned)

Details

Attachments

(1 file)

We got a report of an issue with signature verification in bug 765271: 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
For suggestions for the error cause in bug 765271 comment 109. My Thunderbird installation has been upgraded through automatic updates. Here some more analysis results (all done on OSX 10.6.8): * Downloaded http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/13.0.1/mac/en-US/Thunderbird%2013.0.1.dmg * Compared 'old' Thunderbird.app (Thunderbird_old.app) with file from download above (Thunderbird.app) $ diff -qr Thunderbird.app Thunderbird_old.app | sort Files Thunderbird.app/Contents/MacOS/defaults/pref/channel-prefs.js and Thunderbird_old.app/Contents/MacOS/defaults/pref/channel-prefs.js differ Only in Thunderbird.app/Contents/MacOS: jsloader Only in Thunderbird.app/Contents/MacOS: jssubloader Only in Thunderbird.app/Contents: CodeResources Only in Thunderbird_old.app/Contents/MacOS/defaults: autoconfig Only in Thunderbird_old.app/Contents/MacOS/defaults: profile Only in Thunderbird_old.app/Contents/MacOS/res: broken-image.png Only in Thunderbird_old.app/Contents/MacOS/res: dtd Only in Thunderbird_old.app/Contents/MacOS/res: entityTables Only in Thunderbird_old.app/Contents/MacOS/res: fonts Only in Thunderbird_old.app/Contents/MacOS/res: html Only in Thunderbird_old.app/Contents/MacOS/res: loading-image.png Only in Thunderbird_old.app/Contents/MacOS: active-update.xml Only in Thunderbird_old.app/Contents/MacOS: chrome Only in Thunderbird_old.app/Contents/MacOS: libwidget.rsrc Only in Thunderbird_old.app/Contents/MacOS: libxpcom_core.dylib Only in Thunderbird_old.app/Contents/MacOS: modules Only in Thunderbird_old.app/Contents/MacOS: run-mozilla.sh Only in Thunderbird_old.app/Contents/MacOS: updates Only in Thunderbird_old.app/Contents/MacOS: updates.xml Only in Thunderbird_old.app/Contents: Plug-Ins $ diff Thunderbird.app/Contents/MacOS/defaults/pref/channel-prefs.js Thunderbird_old.app/Contents/MacOS/defaults/pref/channel-prefs.js 1c1 < //@line 2 "/builds/slave/tb-rel-c-rel-osx64-bld/build/mail/app/profile/channel-prefs.js" --- > //@line 2 "/builds/slave/macosx_build/build/mail/app/profile/channel-prefs.js" $ codesign -vvv Thunderbird.app Thunderbird.app: valid on disk Thunderbird.app: does not satisfy its designated Requirement $ codesign -d -r- /Applications/Thunderbird.app Executable=/Applications/Thunderbird.app/Contents/MacOS/thunderbird 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.thunderbird" and anchor apple => This output is for the newly downloaded and installed Thunderbird.app. It's actually the same for the old and new version. For comparison the output of the (working) firefox version: $ codesign -d -r- /Applications/Firefox.app Executable=/Applications/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] = "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 I don't really understand this :), but please let me know if you need more output or if I have to test another version.
Note that when you pass codesign a resource-rules file (using the --resource-rules parameter), the file you pass in must not contain anything besides a "rules" section -- it must not also contain a "files" section. Could that be what's causing trouble here?
(In reply to Steven Michaud from comment #2) > Note that when you pass codesign a resource-rules file (using the > --resource-rules parameter), the file you pass in must not contain anything > besides a "rules" section -- it must not also contain a "files" section. > > Could that be what's causing trouble here? I doubt it. Thunderbird and Firefox are signed using the exact same code (both within the build system and on the signing server). I'll try to dig into it more tomorrow to verify what's happening during signing.
The CodeResources file looks OK to me, modulo not having bug 759318 applied to it: http://hg.mozilla.org/releases/comm-beta/file/54af1cafd26a/mail/app/macbuild/Contents/_CodeSignature/CodeResources vs. http://hg.mozilla.org/releases/mozilla-beta/file/3e1dbfb27e4a/browser/app/macbuild/Contents/_CodeSignature/CodeResources. Other than those minor differences, Thunderbird is signed in exactly the same way, so I don't think this is the issue. What is Contents/CodeResources in your broken build? Is it a regular file, or a symlink? Can you pastebin the contents? Same for Contents/_CodeSignature/CodeResources. Also, what version of OS X are you on?
(In reply to Ben Hearsum [:bhearsum] from comment #4) > What is Contents/CodeResources in your broken build? Is it a regular file, > or a symlink? Can you pastebin the contents? Same for > Contents/_CodeSignature/CodeResources. Also, what version of OS X are you on? I'm testing on OSX 10.6.8, Snow Leopard. Here the versions I use for testing: 1) the version I got with automated update (13.0.1) 2) the version installed from http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/13.0.1/mac/en-US/Thunderbird%2013.0.1.dmg See the attached file from 2) (Contents/_CodeSignature/CodeResources). It's the same in both versions 1) and 2). Interesting is that only version 2) does have the following symlink: CodeResources -> _CodeSignature/CodeResources 1) doesn't have any simlink. Please note that *both* versions are broken (codesign -vvv outputs 'does not satisfy its designated Requirement' for both). So I think you can focus on the version 2) From my understanding the main problem is that $ codesign -d -r- /Applications/Thunderbird.app is missing the part 'anchor apple generic and certificate ...' so Thunderbird.app does not seem to be properly signed (see comment #1 for full output and the output for firefox).
(In reply to elasmo from comment #5) > Created attachment 640769 [details] > Thunderbird.app/Contents/_CodeSignature/CodeResources > > (In reply to Ben Hearsum [:bhearsum] from comment #4) > > What is Contents/CodeResources in your broken build? Is it a regular file, > > or a symlink? Can you pastebin the contents? Same for > > Contents/_CodeSignature/CodeResources. Also, what version of OS X are you on? > > I'm testing on OSX 10.6.8, Snow Leopard. Here the versions I use for testing: > 1) the version I got with automated update (13.0.1) > 2) the version installed from > http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/13.0.1/mac/ > en-US/Thunderbird%2013.0.1.dmg > > See the attached file from 2) (Contents/_CodeSignature/CodeResources). It's > the same in both versions 1) and 2). > Interesting is that only version 2) does have the following symlink: > CodeResources -> _CodeSignature/CodeResources > 1) doesn't have any simlink. OK, that doesn't surprise me. version 1 is subject to bug 758644. That's not going to make a difference, anyways, because both Snow Leopard and Lion ignore Contents/CodeResources. > Please note that *both* versions are broken (codesign -vvv outputs 'does not > satisfy its designated Requirement' for both). So I think you can focus on > the version 2) > > From my understanding the main problem is that > $ codesign -d -r- /Applications/Thunderbird.app > is missing the part 'anchor apple generic and certificate ...' so > Thunderbird.app does not seem to be properly signed (see comment #1 for full > output and the output for firefox). This doesn't surprise me either. This is bug 765271 and it's only resolved for recent 14.0 betas. There's nothing we can do about 13/13.0.1 at this point, but it'll be fixed in 14.0. Unless you're still hitting the "missing or invalid" error on your version 2, I think this is either WORKSFORME or a dupe of bug 765271.
(In reply to Ben Hearsum [:bhearsum] from comment #6)> > > > > From my understanding the main problem is that > > $ codesign -d -r- /Applications/Thunderbird.app > > is missing the part 'anchor apple generic and certificate ...' so > > Thunderbird.app does not seem to be properly signed (see comment #1 for full > > output and the output for firefox). > > This doesn't surprise me either. This is bug 765271 and it's only resolved > for recent 14.0 betas. There's nothing we can do about 13/13.0.1 at this > point, but it'll be fixed in 14.0. At the when I tested I was using Thunderbird%2014.0b4.dmg in which bug 765271 did not seem to be fixed. > Unless you're still hitting the "missing or invalid" error on your version > 2, I think this is either WORKSFORME or a dupe of bug 765271. Tested with the newest beta from https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/14.0b5-candidates/build1/mac/en-US/Thunderbird%2014.0b5.dmg Now everything seems fine. $ codesign -d -r- Thunderbird.app Executable=/Volumes/Thunderbird/Thunderbird.app/Contents/MacOS/thunderbird designated => identifier "org.mozilla.thunderbird" 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 $ codesign -vvv Thunderbird.app Thunderbird.app: valid on disk Thunderbird.app: satisfies its Designated Requirement => The initial problem (re-prompting for key chain access) does also not appear anymore with this version. Looks good now.
Thanks for your help in debugging this!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: