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

Categories

(Firefox :: Preferences, defect)

10 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 19

People

(Reporter: gabriel, Assigned: robert.strong.bugs)

Details

Attachments

(1 file)

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.
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+
https://hg.mozilla.org/mozilla-central/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.