569522 - Sparkle can sometimes send an update request with a version parameter that doesn't match the app version

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sam has been telling me off and on about update pings that send the wrong version in their URL, e.g. 

203.42.177.18 - - [27/Apr/2010:06:25:42 +0000] "GET /update-check?os=10.5.6&arch=x86&version=1.6.7&intl=0&lang=en HTTP/1.1" 200 1089 "-" "Camino/2.0.2 Sparkle/1.5"

[11:13pm] smorgan: sauron: I can see how there is a pref setting that would cause this, but not how it would come about. I wonder if it's something with switching between 1.6 and 2.0, and the migration getting confused...
[11:14pm] smorgan: sauron: and they would have to be running a custom build
[11:15pm] sauron: smorgan: heh, ok
[11:15pm] smorgan: sauron: except that doesn't make sense because the base URL wouldn't be there
[11:15pm] smorgan: WTF
[11:15pm] smorgan: Oh, nm
[11:16pm] smorgan: It wouldn't have to be
[11:16pm] smorgan: sauron: how common is this?
[11:16pm] sauron: [10:57pm] sauron: i don't know if it's just the large installs, or if it's all over and we only notice the 10K+ installs
[11:17pm] sauron: need ss to pick up the phone and answer 
[11:17pm] smorgan: ah
[11:17pm] sauron: he's always mentioned it the same time he's doing a 10+K install phonehome
[11:35pm] smorgan: If I'm right about how the weird check is happening, I think I can fix it
[11:35pm] smorgan: I'm still not sure how someone would get into this state though
[11:38pm] smorgan: And if I'm right the bug is that it's checking for updates, not that the string is wrong
[11:38pm] sauron: ?
[11:39pm] smorgan: When we initialize prefs on each startup, we set up the Sparkle stuff
[11:39pm] sauron: mhm
[11:39pm] smorgan: The only way I can see to not have the manifest URL set is if the bundle has NO for the update check key
[11:40pm] smorgan: Meaning, it's a build made without update support
[11:40pm] smorgan: In that case, we leave the function early (because, why bother?)
[11:40pm] sauron: ok
[11:40pm] smorgan: But, if somehow they had that same key set to YES in their prefs, Sparkle would autoupdate
[11:41pm] sauron: and wouldn't have picked up the current details for the URL
[11:42pm] smorgan: Right

We may not be able to "fix" this, but at least now we have a bug on it for storage of useful related information ;)

Comment 1

[Stuart Morgan]

Attachment: fix?

This is speculative. I don't know how someone could reasonably get into this state (although I haven't got back and re-learned how we set prefs in 1.6), but the only way I can see for someone to have a stale URL but still be checking for updates is if the pref says to check for updates, but the build itself has updates disabled, and this should fix that case.

It certainly won't hurt (since it only affects builds where the app's plist says update checks are disabled), and we can re-evaluate after it ships.

Comment 2

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 448933 [details] [diff] [review]
fix?

sr=pink

Comment 3

[Stuart Morgan]

Landed http://hg.mozilla.org/camino/rev/f45b10224cfb
We'll hope for the best and call this fixed, and if it keeps happening re-open it.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on CVS trunk and CAMINO_2_0_BRANCH for Stuart so that he'll never have to touch CVS again ;)

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

So, the last couple of weeks I've noticed some irrational spikes in the update logs, and I just ran the last two weeks through dump-ips to get more info, then started grepping the identified IPs.

The first one I checked contributed 28+K pings in one day in the format of:
> <IPRedacted> - - [01/Sep/2012:07:33:56 -0700] "GET /update-check?os=10.6.4&arch=x86&version=2.0.4&intl=0&lang=en HTTP/1.1" 200 1077 "-" "Camino/2.1.2 Sparkle/1.5"
from 07:33 to 12:09, usually pinging 1x or 2x/second.

They all seem to be of that form, except for 2 IPs that were 2.0.9/2.04 instead:
> <IPRedacted> - - [27/Aug/2012:16:01:26 -0700] "GET /update-check?os=10.6.4&arch=x86&version=2.0.4&intl=0&lang=en HTTP/1.1" 200 1077 "-" "Camino/2.0.9 Sparkle/1.5"

It's almost like 1 guy is wandering around Kalamazoo, MI with this bug, and whenever he plugs into a network, his Camino starts slamming us with pings.

(Curiously, we patched this bug for 2.0.4, and 2.0.4 is the reported wrong version in all of these pings.)

Comment 6

[Chris Lawson (gone)]

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #5)

> It's almost like 1 guy is wandering around Kalamazoo, MI with this bug, and
> whenever he plugs into a network, his Camino starts slamming us with pings.

Should I set up a trap? :-p

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to Chris Lawson from comment #6)
> > It's almost like 1 guy is wandering around Kalamazoo, MI with this bug, and
> > whenever he plugs into a network, his Camino starts slamming us with pings.
> 
> Should I set up a trap? :-p

Yes, please!  He's worse than Brazil guy (who was just 1 IP, and initially only once every few months) :-P

What's interesting is that the Kalamazoo Bandit suddenly went from ~2 pings/day to mass-ping insanity between 8-15 and 8-16 (the spike in pings on the 17th is what tipped me off to this a few weeks ago; I just hadn't had time to investigate, and then re-run that week's stats, until now).  As in, after I blacklisted his current IPs and re-ran the August 12-19 stats, the Aug 12-15 users now differed from the first run by 2-3 pings/day, whereas subsequent days differed from the first run by 30K-60K pings/day.

Corrupt org.mozilla.camino.plist, or he can't write to it, so that he's got an old/bad SUFeedURL stored and can't update the SULastCheckTime either, causing 2-3 pings/second since Sparkle never thinks it's checked?