390746 - Software Update displays "AUS: Update XML File Malformed (200)" if system clock is off

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P4)

Description

[(not reading, please use [e-mail] instead)]

Software Update displays "AUS: Update XML File Malformed (200)" if system clock is off.

cbeard has a laptop that is stuck on 1.5.0.8.  When he attempts to update, he gets the "AUS: Update XML File Malformed (200)" message.

note, I believe fx 2.x and trunk would have the same bug.

this error is our catch all error message for onError(), see
http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/src/nsUpdateService.js.in#2009

what's going on is since his system clock is off, the https request fails.  (If I try the same request manually, I get the a prompt, see screen shot #1).

we have a lot of people stuck on old releases.  But my instinct is that not all of them have bad system clocks.

todo items:

1)  propogate the onError() value into the UI and into the console log, for better diagnosis.  Note, for the branch, we can't change any strings.

2)  present a better error message in this scenario:  for example "the adjust your system clock" (again, see screen shot #1).  AGain, for the branch, we can't change any strings.

3)  send over an http request header (like If-Modified-Since or perhaps X-Update-Date?) so we can see, going forward, if people are failing for this reason.  (If we had this header, on the AUS side, we would know if people asking for a version kept asking because they had bad clock time.  of course, this only helps future versions of firefox, not existing users.)  In the spin off bug, I'll see what morgamic things about abusing the If-Modified-Since header or adding a custom HTTP header.

4)  write a support article for support.mozilla.org about "seeing this XML error during update? check your system clock (and make sure you are online, see bug #312661"

thanks again to cbeard for letting me poke at his laptop.

Comment 1

[Steffen Wilberg]

The same catch-all error is displayed when Firefox is offline (bug 312661).

Comment 2

[Michael Morgan [:morgamic]]

Hey Seth, I'm all for abusing headers, sounds fun.  Is it worth a one-off hacky fix?  How many users are affected by it?

Comment 3

[(not reading, please use [e-mail] instead)]

> Is it worth a one-off hacky fix?  How many users are affected by it?

unfortunately, we don't know how many users are affected until we report back the date.

my guess is that this is *not* the main cause of users stuck on old releases.

but, it still might be worth doing.

keep in mind that if we make the change to send this header, those users stuck on old versions of firefox won't get that version of firefox with that fix (unless they manually install), because they can't update.

Comment 4

[(not reading, please use [e-mail] instead)]

al billings asks:  how far off does the system clock have to be for this bug to be hit?

great question, I'll look into that.

Comment 5

[Robert Strong (they/them - no direct email)]

I tried on Vista with my clock being off by over a year in the past and wasn't able to reproduce.

Comment 6

[Jason Barnabe (np)]

(In reply to comment #0)
> 4)  write a support article for support.mozilla.org about "seeing this XML
> error during update? check your system clock (and make sure you are online, see
> bug #312661"

Bug 398814

Comment 7

[Mike Connor [:mconnor]]

Not going to continue to block on this.  If you disagree with this decision, please renominate with reasons why we can't ship with this in final

Comment 8

[Serge Gautherie (:sgautherie)]

cbeard, or anyone who can reproduce,
could you check the behavior of FF 3.1a2, (before/)after bug 312661 checkin ?

In any case, what is the true status value (which is overridden by the '200' one) for this bug ?

Comment 9

[Robert Strong (they/them - no direct email)]

I was able to reproduce... we don't have strings for ssl errors and fallback to the default - cbeard, don't bother with trying to reproduce.

Comment 10

[Robert Strong (they/them - no direct email)]

status code is 2153390069

error is sec_error_expired_certificate

Comment 11

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Comment 12

[Jennifer Morrow [:Boriss] (UX)]

seth - where is this screen shot #1?

Comment 13

[Robert Strong (they/them - no direct email)]

Attachment: screenshot

boriss... the patch adds a new error string for this case and uses the existing error ui wizard page. If there are changes to be made to the existing ui (which I think may be a good idea) it should be done in a separate bug.

Note: it is important to get the *right* string the first time for these error message since the code finds the string by prefixing the error code and then looks it up in a properties file. If we have to change it then we would normally change all of the prefixes so l10n will see the change. It is an ugly way to do it and has been the way we handle this for errors in other parts of the code.

btw: bug 447047 is essentially the same type of change as this bug... do you want a screenshot for it as well?

Cheers,
Robert

Comment 14

[Robert Strong (they/them - no direct email)]

btw: we may want to make the beginning of the string some form of mixed caps as the other strings follow this convention.

Comment 15

[Jennifer Morrow [:Boriss] (UX)]

Since we're not changing the wording of all the error strings in this bug (I'll file another bug for this), I think you're right that this one should conform as well as possible with the style of the others for now.  How about "Server certificate has expired (Please adjust your system clock to the correct time or contact your Administrator)" ?

Comment 16

[Robert Strong (they/them - no direct email)]

(In reply to comment #15)
> Since we're not changing the wording of all the error strings in this bug (I'll
> file another bug for this), I think you're right that this one should conform
> as well as possible with the style of the others for now.  How about "Server
> certificate has expired (Please adjust your system clock to the correct time or
> contact your Administrator)" ?

That sounds good though I'd like to make a small change to make it less authoritative regarding the system clock being off
"Server certificate has expired (Please adjust your system clock to the correct time if it is incorrect or contact your Administrator)"

Comment 17

[Jennifer Morrow [:Boriss] (UX)]

Sounds good.  It seems some of the current strings have Please and some don't... I guess some server errors are more polite than others.

Comment 18

[Robert Strong (they/them - no direct email)]

Attachment: patch

I received a verbal from boriss on the string

Comment 19

[Dave Townsend [:mossop]]

Comment on attachment 336707 [details] [diff] [review]
patch

Seems weird to capitalise Administrator, but I guess if Boriss is ok with it then so am I.

Comment 20

[Robert Strong (they/them - no direct email)]

(In reply to comment #19)
> (From update of attachment 336707 [details] [diff] [review])
> Seems weird to capitalise Administrator, but I guess if Boriss is ok with it
> then so am I.
I agree but this capitalization is consistent with the other error strings. They all need some sanitizing like we did for the EM around 2.0.

Comment 21

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/21d31b2f7cfcbff0b8d23972baa60e85e58f325f

Comment 22

[Robert Strong (they/them - no direct email)]

Filed bug 453666 to review the existing error strings

Comment 23

[Robert Strong (they/them - no direct email)]

Attachment: patch for test (checked in)

http://hg.mozilla.org/mozilla-central/rev/1e32a7b9bd2f31c567a416ae9d7cccbbd0147be5

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Rob, when I set my system clock to a date like 14.02.2030, the certificate of the server isn't valid anymore. Isn't it the same situation as having the system clock off? I can still see this error. I even can't find a bug which covers such a situation. Shall I file a new one? If yes, how can I verify this one?

Comment 25

[Robert Strong (they/them - no direct email)]

Henrik, what does the dialog show specifically? The error comes from XHR so if it has a different error than 2153390069 which was the case for the system clock being set back in time as what happened with cbeard's original report (e.g. this bug) then it should be a new bug.
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/update/updates.properties#102

Set app.update.log.all to true and report the error code from the error console when you set the date forward in a new bug.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, filed as bug 478533.

This bug has the wanted1.9 flag. Do we still wanna back-port it? I don't think so due to the string changes.

Comment 27

[Robert Strong (they/them - no direct email)]

Not as far as I'm concerned unless drivers want to get the l10n teams to backport the string.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #27)
> Not as far as I'm concerned unless drivers want to get the l10n teams to
> backport the string.

Samuel, could you make a decision please?

Comment 29

[Samuel Sidler (old account; do not CC)]

(In reply to comment #4)
> al billings asks:  how far off does the system clock have to be for this bug to
> be hit?
> 
> great question, I'll look into that.

I didn't see an answer to this question.

Rob: How far off are we talking?

Comment 30

[Robert Strong (they/them - no direct email)]

In cbeard's case he was back to around the beginning of UNIX time (e.g. January 1, 1970) due to his battery dying and the clock being reset. When I tested I had to go back several years... I believe the clock has to go back to a time prior to the cert being issued.

btw: most systems sync their clock using internet time servers so this shouldn't happen very often.

Comment 31

[Samuel Sidler (old account; do not CC)]

Yeah, this seems like it's an unlikely cause for any update problems we're seeing (at least on a large scale). This isn't worth the l10n porting effort for 1.9.0.

Thanks Rob.