Closed Bug 800307 Opened 7 years ago Closed 7 years ago
Update certificates are checked even if app
.update .url .override is set in Thunderbird >= 10 .0 .7esr
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Steps to reproduce: We push out our own updates of Thunderbird by setting app.update.url.override to our own url. This has worked fine up to version 10.0.7esr. Now when a user tries to update to 10.0.8esr, no update is found even though we have made 10.0.8esr available for the users. Actual results: In the error log, the following is shown: Error: Expected certificate attribute 'issuerName' value incorrect, expected: 'OU=Equifax Secure Certificate Authority,O=Equifax,C=US', got: '<our certificate provider>'. Source File: resource://gre/modules/CertUtils.jsm Line: 103 Error: Expected certificate attribute 'commonName' value incorrect, expected: 'aus3.mozilla.org', got: '<our certificate name>'. Source File: resource://gre/modules/CertUtils.jsm Line: 103 Error: Certificate checks failed. See previous errors for details. Source File: resource://gre/modules/CertUtils.jsm Line: 106 Apparently, version 10.0.7esr (and newer) checks the app.update.certs.x.commonName and app.update.certs.x.issuerName event though app.update.url.override is set. Expected results: The certificate checks should have been skipped since app.update.url.override is set. This was the case in all versions we have tried including 10.0.6esr.
basically a dupe of bug 770594
Component: General → Application Update
Product: Thunderbird → Toolkit
Version: 10 → 10 Branch
IMHO this is not a dupe. These checks were enabled for Thunderbird (ESR) in changeset 9898:1d4617eeb9bd (http://hg.mozilla.org/releases/comm-esr10/rev/1d4617eeb9bd) and the comments specifically states "This validation will not be performed when using the |app.update.url.override| preference for update checking." Apparently it does not work as the programmer intended since the checks are being performed even though we are using app.update.url.override. The other bug deals with certificate validation through a proxy without having "app.update.url.override" set. But if this bug is fixed, I guess it could be used as a workaround for bug 770594.
7 years ago
Component: Application Update → Preferences
Product: Toolkit → Firefox
Assignee: nobody → robert.bugzilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #670440 - Flags: review?(dtownsend+bugmail)
Attachment #670440 - Flags: review?(dtownsend+bugmail) → review+
Pushed to mozilla-inbound https://hg.mozilla.org/integration/mozilla-inbound/rev/c3b088d2af95
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
I may be a bit confused, but even if the comment now states that app.update.override.url is only to be used for testing, the fact remains that the certificate checks are still performed when app.update.override.url is used. Either the code comment should be changed (again) to state that app.update.cert.checkAttributes is the only way to bypass certificate checks, or we need to investigate why app.update.override.url doesn't disable the checks.
(In reply to gabriel from comment #6) > I may be a bit confused, but even if the comment now states that > app.update.override.url is only to be used for testing, the fact remains > that the certificate checks are still performed when app.update.override.url > is used. Either the code comment should be changed (again) to state that > app.update.cert.checkAttributes is the only way to bypass certificate > checks, or we need to investigate why app.update.override.url doesn't > disable the checks. It requires a user pref and not a default pref. http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#2829
Ah. Thanks for clearing that up. I guess it would not hurt to clarify that in some documentation (mozillazine?) regarding the settings.
You need to log in before you can comment on or make changes to this bug.