All users were logged out of Bugzilla on October 13th, 2018

Nightly rejecting SSL certs with sec_error_untrusted_issuer only on Win64 profiling branch builds

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
7 years ago
2 years ago

People

(Reporter: taras.mozilla, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 597856 [details]
error message

Todays nightly went paranoid on me. Refuses to let me see any ssl site.
(Reporter)

Comment 1

7 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

7 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

7 years ago
Created attachment 597930 [details]
NSPR_LOG_MODULES=pipnss:5,nsSocketTransport:5
See comment 2. Do bbondy and rs have any ideas here?
Component: Networking: HTTP → Security: PSM
QA Contact: networking.http → psm
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.
$ 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

7 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

7 years ago
Ehsan, do you have any ideas on what might cause the builds to diverge?
bah... I was comparing with an x86 installer. :(
(Reporter)

Comment 10

7 years ago
Ehsan, how does one push a build to try to get something similar to the profiling build?
Summary: Nightly rejecting SSL certs for bugzilla/google, etc → Nightly rejecting SSL certs with sec_error_untrusted_issuer only on Win64 profiling branch builds
Issues with the updater (i.e. why those 4 files are different) mentioned above are now part of bug 727982
(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.
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
Duplicate of this bug: 739325

Comment 15

7 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
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.