Closed
Bug 727873
Opened 12 years ago
Closed 8 years ago
Nightly rejecting SSL certs with sec_error_untrusted_issuer only on Win64 profiling branch builds
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: taras.mozilla, Unassigned)
References
Details
Attachments
(2 files)
Todays nightly went paranoid on me. Refuses to let me see any ssl site.
Reporter | ||
Comment 1•12 years ago
|
||
The only thing possibly relevant in the error: Timestamp: 2/16/2012 9:16:06 AM Error: [Exception... "null" nsresult: "0x805a1ff3 (<unknown>)" location: "JS frame :: resource:///modules/services-sync/resource.js :: Channel_onStopRequest :: line 578" data: no] Source File: resource:///modules/services-sync/resource.js Line: 578
Reporter | ||
Comment 2•12 years ago
|
||
Looks like something went wrong during app-update. My build consistently fails to do ssl, even with a new profile. Here is my firefox dir: http://dl.dropbox.com/u/5961467/firefox.ssl-screwed.zip It's off the profiling branch, so one can get useful symbols for it easily.
Reporter | ||
Comment 3•12 years ago
|
||
Comment 4•12 years ago
|
||
See comment 2. Do bbondy and rs have any ideas here?
Component: Networking: HTTP → Security: PSM
QA Contact: networking.http → psm
Comment 5•12 years ago
|
||
I compared the installer for this build, the screwed up install, and the last-update.log and like the partial mar didn't contain all of the new files for this build. This is likely due to a mar generation error so cc'ing a couple of releng people.
Comment 6•12 years ago
|
||
$ diff -r firefox-x64-profiling firefox-screwed Only in firefox-screwed: active-update.xml Only in firefox-screwed/uninstall: uninstall.update Only in firefox-screwed: updates Only in firefox-screwed: updates.xml Files firefox-x64-profiling/freebl3.chk and firefox-screwed/freebl3.chk differ Files firefox-x64-profiling/nssdbm3.chk and firefox-screwed/nssdbm3.chk differ Files firefox-x64-profiling/omni.ja and firefox-screwed/omni.ja differ Files firefox-x64-profiling/softokn3.chk and firefox-screwed/softokn3.chk differ So, it seems like there may be some problem with the updater, since I expect that all four of the differing files to be the same. However, I am able to reproduce this particular bug even on a clean Nightly 2012-02-15 Win64 profiling branch build. However, normal mozilla-central Win32 and Win64 builds work fine, as do Win32 profiling branch builds. So, this particular bug might be unrelated to the above-noted updater issue, and instead it might be a problem with the Win64 profiling branch build config.
Reporter | ||
Comment 7•12 years ago
|
||
I can confirm that the updater has nothing to do this this. I accidentally grabbed a 32bit profiling build to compare against. 64bit profiling builds exhibit the issue, all others do not.
Reporter | ||
Comment 8•12 years ago
|
||
Ehsan, do you have any ideas on what might cause the builds to diverge?
Comment 9•12 years ago
|
||
bah... I was comparing with an x86 installer. :(
Reporter | ||
Comment 10•12 years ago
|
||
Ehsan, how does one push a build to try to get something similar to the profiling build?
Updated•12 years ago
|
Summary: Nightly rejecting SSL certs for bugzilla/google, etc → Nightly rejecting SSL certs with sec_error_untrusted_issuer only on Win64 profiling branch builds
Comment 11•12 years ago
|
||
Issues with the updater (i.e. why those 4 files are different) mentioned above are now part of bug 727982
Comment 12•12 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #11) > Issues with the updater (i.e. why those 4 files are different) mentioned > above are now part of bug 727982 Just to be clear: there's no issue with the _updater_ when files between a ZIP and a MAR differ. ZIPs and MARs are staged differently and due to build system limitations this means that NSS .chk files and omni.ja will differ.
Comment 13•12 years ago
|
||
Some observations: - I noticed this problem also happens on elm x64 builds. - I noticed that if you replace xul.dll with an m-c version from the same day for both the Profiling and Elm, it fixes the problem and updates are found. - Changing app.update.log to true and running firefox with -console produces this log: download | new post *** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist *** AUS:SVC getLocale - getting locale from file: resource://app/update.locale, locale: en-US *** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3 /Firefox/13.0a1/20120222174716/WINNT_x86_64-msvc/en-US/nightly-elm/Windows_NT%20 6.1.1.0%20(x64)/default/default/update.xml?force=1 *** AUS:SVC gCanCheckForUpdates - able to check for updates *** AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.o rg/update/3/Firefox/13.0a1/20120222174716/WINNT_x86_64-msvc/en-US/nightly-elm/Wi ndows_NT%206.1.1.0%20(x64)/default/default/update.xml?force=1 *** AUS:SVC Checker:onError - request.status: 2153390067 *** AUS:SVC getStatusTextFromCode - transfer error: Update XML file malformed (2 00), default code: 200
Comment 15•12 years ago
|
||
Sorry for my lag on this. To get something similar to the profiling branch from the try server, there are two ways: 1. Just add --enable-profiling to the mozconfig. 2. Clone http://hg.mozilla.org/projects/profiling and push to try from there. I highly recommend the first approach.
I don't think there's anything actionable here (that profiling project looks defunct anyway - the last change was in 2013).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•